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ABSTRACT 


The relational database model has become the most 
popular and widespread database model. Most current 
database systems are based upon or related to the relational 
model. However, the relational model is beset with 
Significant limitations, pitfalls and deficiencies. The 
relational model can be substantially improved with 
graphical interfaces. To this end, the Graphics Language 
for Accessing Database (GLAD) can provide easy to use and 
learn graphics interfaces for the relational model. Data 
structures and algorithms for GLAD will be presented to 


extend the relational model. 
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Although considerable work has been accomplished on 
extending and improving data models with graphical 
Mmmeertaces, the graphical or pictorial approach to 
representing a database is far from being fully explored. 
The potential of this approach has not been fully realized 
with current database systems that use a pictorial 
representation of the data stored in the database. 
Therefore, many more approaches will be proposed, explored 
and implemented before graphical interfaces for database are 
maximized for the best possible user environment and 
powerful semantic extension of a basic data model. 
Graphical interfaces can be employed to extend the user 
Capabilities of the entire audience of database users. 1a) 
particular, the naive user will greatly benefit from 
graphical interfaces to a database model. 

Progress with graphics interfaces has largely been 
confined to academic and prototype systems. Most current 
database systems have poor user interfaces that do not 
represent data in an easily understandable manner. Higie 
example, the popular relational database system represents 
data as tuples in tables. The user interface is a standard 
relational type of query language that has no graphical or 


pictorial features. Without good user interfaces, most 


database systems are beset with drawbacks, pitfalls and 
limitations for the database user. These limitations can be 
resolved by extending the capabilities of these systems with 
additional features and by adding easy to use and learn 


database interfaces. 


A. GLAD WILL RESOLVE SEMANTIC LIMITATIONS 

Limitations with many basic data models, such as the 
relational model, are widely recognized. These limitations 
are caused by lack of semantic capability. Implementations 
of inadequate semantic models can result in systems that are 
difficult to learn and use. When implemented, the Graphics 
Language for Accessing Database (GLAD), proposed in Wu [Ref. 
lepp. 1-11], will provide a user with semantic capabilities 
that a basic model does not have and a friendly, easy to use 
and learn pictorial database environment. GLAD will 
ultimately eliminate many of the deficiencies that make the 
relational model difficult for the naive database user to 
learn and use. The naive database user will be able to 
access and manipulate a database with a minimum amount of 
atreevculty., GLAD will utilize a unique graphics object 
approach to eliminate the relational model's deficiencies 


and limitations. 


B. GRAPHICS OBJECTS IN GLAD 
GLAD shall utilize Graphics Objects to pictorially 


represent data items as simple pictorial objects. These 


graphics objects will represent information that is stored 
in the database. When dealing with a database, it is 
natural for the user to picture objects or entities of the 
database and the connections that may exist between the 
entities. GLAD will provide the user with simple rectangles 
to represent entities or database objects and lines that 
connect the objects. This approach will be superior to 
simply reviewing current representations of the schema. 
1. GLAD Will Extend And Improve The Relational Model 

GLAD shall be utilized to extend the basic 
relational model that was developed in the early seventies 
and refined with a decade of theoretical research and 
implementation. The relational model's wide spread 
acceptance, popularity and successful commercial 
implementation has made it today's most dynamic and widely 
used data model. However, the relational model has 
significant deficiencies and limitations that makes it a 
perfect candidate for extension by GLAD. The successful 
design and implementation efforts of systems such as DB2 and 
INGRES can be built upon to take advantage of work that 
painstakingly and previously has been accomplished. 
Resources can be totally allocated to developing an 
effective higher level interface. The higher level 
interface that will be provided by GLAD will be a 


substantial improvement over the standard query language. 


C. STANDARD RELATIONAL LANGUAGES 

Relational Query Languages are difficult to learn and 
use. Semantic difficulties associated with high level, non- 
procedural languages should be reduced as much as possible 
or totally eliminated. GLAD will provide graphical 


interfaces that eliminate the syntactic difficulties of 


standard relational models. Semantic power and capability 
shall be added to the basic model. GLAD will support 
complex objects and data types. These additional 


capabilities will make the database environment easier to 


WELLIize. 


abs Standard Query Languages Are Unsuitable For 


End Users 

Difficulties associated with standard relational 
languages makes them unsuitable as an end user language for 
a database. High level, non-procedural languages, such as 
QUEL or SQL, are designed to allow the end-user to avoid 
mastering the details of the embedded programming language. 
Thus, the user does not have to understand the syntax, 
semantics, data structures and other features of an embedded 
host language, effectively eliminating the difficulties of 
navigating the data through the system. The user is only 
required to manipulate the high level set language commands 
to formulate the query. However, the use of set language 
constructs to formulate queries is not always a trivial 
task. A significant amount of syntax and semantics must be 


mastered to formulate meaningful queries. 


2. An Environment That Is Unsuitable For Naive Users 

The standard query language environment is not well 
suited to naive database users. Learning and using a 
conventional query language is difficult for users with or 
without only minimal computer science and mathematics 
background. This situation is unacceptable because the 
difficulties associated with mastering the syntax and 
semantics of conventional query language handicaps a large 
portion of the database user populace. The standard 
relational environment must be improved for this’ large 
category of users. Systems that do not consider large 


segments of the user populace will ultimately be replaced. 


D. IMPROVING THE RELATIONAL ENVIRONMENT 

Considerable work has been accomplished in softening the 
harsh and unfriendly environment presented to the user by 
systems that are based on the relational model. eens 
difficult for an office worker, administrator or secretary 
to relate to data representation and presentation in a 
manner that is dissimilar and seemingly unrelated to the 
normal way that they obtain, review and process data. Human 
factors studies have shown systems that relate new require- 
ments to familiar concepts are easier for workers to learn 
and use than systems that do not consider a user's working 


environment and previous experience. 


1. QBE and Electronic Forms 

Systems such as QBE by Zloof [Ref. 2:pp. 324-342] 
and Query by Electronic Forms by Miyao [Ref. 3:pp. 17-25] 
have largely remedied the above mentioned problem. With 
QBE, the user is supplied example queries that can be used 
to formulate his associated query. The example query serves 
as a template for query formulation. Although this approach 
is powerful as a learning aid or tool, it is limited to a 
finite amount of frequently used query examples. If “ee 
user wants to formulate an unusual or complex query, he may 
be unable to find a QBE example to serve as a template for 
his extraordinary requirement. The Electronic Forms System 
provides a type of graphical representation of a form or 
document that is similar to an office form that is used in 
the business environment. The advantage of this approach is 
the correlation between the paper form and the electronic 
display screen. The mechanism that is presented to the user 
for accessing data is similar to a real world paper form 
that exists in his office environment. The drawback is that 
the Electronic Forms approach is very limited in scope and 
must be individually tailored to the business environment. 
Nevertheless, these system's graphical approaches to aiding 
the user are a significant improvement in ease of access for 


the database user. 


2. The Early Graphical Approaches 


Many of these early graphical approaches to database 
are user friendly but lack powerful semantic capabilities. 
In developing a graphical system for database representation 
and access, we not only want to provide a user friendly 
environment but also want to add additional semantic 
capability to the basic relational model. In particular, 
the graphical system must have the semantic capability of 
direct representation of non-atomic data. 

3. Relational Data Representation 

The basic relational model is unable to directly 
represent certain types of data. This shortcoming is due to 
the relational model's view of data stored as atomic types 
in tables. An experienced user may be able to indirectly 
represent non-atomic types of data by joining successive 
tables of data together to ultimately represent a complex 
data type. Unfortunately, this technique requires 
substantial knowledge of database beyond the scope of what 
should reasonably be expected from a naive database user. 
Glad will provide complex data type representation of non- 
atomic data. The details of this type of data representa- 
tion will be entirely shielded from the user. To the user 
point of view, a complex data type is handled the same way 
aS an atomic data type, such as integer, real or char. [In 
fact, this is certainly not the case. A significant effort 


will be required to allow these special kinds of data to be 


directly represented in the GLAD implementation. However, 
from the user view, the complex data types are accessed 
GQirectly because the implementation of non-atomic data 
representation will make data retrieval transparent to the 
end-user. Therefore, GLAD will resolve a serious relational 
database limitation, the inability to express and represent 
certain kinds of non-atomic information. 
4. Lack of Semantic Features 

The basic relational model lacks powerful semantic 
features. In addition to the previously mentioned problems, 
the relational model has the following semantic 
deficiencies: 


1. It is unable to represent generalized entities as 
composites of more specialized entities. 


2. The relational model is unable to represent aggregate 
entities as a collection of atomic and non-atomic sub- 
enticiles. 


3. It is unable to classify instances of certain types of 
objects. 


4. The relational model can not show the associations 
between entities in the database. 


5. GLAD Will Eliminate Relational Problems 
A lack of powerful higher-level abstraction repre- 
sentation prevents the basic relational model from providing 
a powerful and flexible user interface. The basic 
relational system can not accurately represent and display 
entities of a real world environment that are composed of 
both complex and simple sub-entities. GLAD will eliminate 


all of the previously mentioned semantic limitations by 


supporting the following powerful abstract database 


Sencepcs: 
1. aggregation 
2. classification 
3. generalization 
4. association. 


6. Object Oriented Approach 


Powerful abstraction concepts such as the above 
mentioned aggregation, classification, generalization and 
association are best implemented with object oriented 
programming. These concepts require objects to be 
represented as composites of other objects with 


specializations and generalizations of object type. 


E. GLAD DEVELOPMENT 

GLAD is being developed with an object’ oriented 
programming approach. The object oriented approach for 
database development seems to be well suited for database 
representation. Database objects can be designed to 
represent real world entities in a natural and realistic 
manner. The object oriented approach is well suited for 
supporting complex data types and powerful semantic 
features. Conventional programming languages separate data 
and program instructions. This separation severely limits 
the capability of a conventional high level language to make 
an easily understandable representation of real world data 


objects. 


1. GLAD As An Extension of The Relational Database 

GLAD will combine object oriented graphics 
interfaces with a standard relational database system. ita 
essence, GLAD sits on top of the relational model and adds 
cbject oriented flavor to the standard relational system. 
Therefore, the combined system is neither purely object 
oriented nor set oriented. The new system will ultimately 
be the synthesis of the high level, object oriented, 
graphics interfaces and the basic relational database 
system. 

Since GLAD will be built on top of a relational 
model, the object oriented graphics language must have the 
ability to interface with the relational model. Queries 
that are received in GLAD'S object oriented syntax must be 
translated into relational syntax to access data that is 
stored in the relational backend. The retrieved data, in 
relational format, must be reformatted to object oriented 
syntax and ultimately displayed to the user via the graphics 
interface. 

2. The High Level Interface 

GLAD provides an effective data manipulation 
interface for the database. The graphics objects are 
actually used to access the information contained in the 
database. This approach seems to be well suited for easy 


learning and use by all categories of users because GLAD 
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uses a single coherent interaction method for both the data 
manipulation and the data application program interactions. 
The high level, graphics interface objects provide 

the basis for this thesis research. This research is a 
portion of a project that is using ACTOR by Whitewater [Ref. 
4:pp. 25-115], an object oriented programming language, to 
develop a user friendly interface to the relational database 
model. In addition, GLAD's implementors hope to provide a 
semantically rich data model that users directly manipulate 
in gathering information with a minimum amount of effort. 
This thesis is done in conjunction and in parallel with 
research on a data manipulation and data definition language 
for GLAD. The above mentioned areas will not explicitly be 
covered in this paper. References to the parallel areas 
will only be made in conjunction with data structures or 
translation of the information that is held in the object 
oriented interface. 
F. DATA STRUCTURES AND ALGORITHMS FOR THE 

GRAPHICS INTERFACE 

This study's primary focus is the definition of data 
structures to store data that is pertinent to the designated 
database and development of algorithms that shall be 
utilized to translate object oriented information into 
relational syntax. To this end, SQL like syntax will be 
used to illustrate the translations. In addition, careful 


consideration must be given to how data shall be stored in 
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the object oriented paradigm. There are many possible ways 
to store data within the system. Data should be stored ina 
manner that will maximize effective and efficient transla- 
Cron Of secondary importance is an analysis of the basic 
relational model's deficiencies and validation of the need 


for a graphical interface. 


G. OUTLINE 
This research shall present one major topic per chapter. 
Higher level abstractions for the graphics interfaces will 
be discussed in conjunction with the major focus of this 
thesis: data structures and algorithms for supporting the 
graphics interfaces. A simulator using the translation 
algorithm is included in Appendix A to show possible GLAD 
translations and Appendix B to show translated output. In 
addition, a brief conclusion will be offered in support of 
the major topics. The major topic areas of this thesis are 
presented in the following manner: 
i. Entroduceion 
2. The Need For An Interface And Extension 
3. Object Oriented Languages For Graphics Interfaces 
4. The Query Windows 
5. Data Structures To Support The Interfaces 
6. Algorithms For The Translation 
72) SSonelusiton. 
The above listed topics are presented from a higher 


level perspective to a lower level perspective to present a 
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coherent argument for GLAD as an object oriented database. 
In addition, data structures and algorithms to support this 
interface shall be discussed in detail. The topics are 
presented to show the user a higher level, abstract view of 
the requirement and a possible scheme for the physical 
implementation of the interface. 
i Introduction 
iimeche wdiintroauction, ) the major topics of this 
research were introduced. The introduction shall preview 
the entire thesis and lead into the need for a graphics 
interface. 
2. The Need For An Interface And Extension 
In Chapter II, the need for an interface to the 
relational model will be validated. Chapter II will explore 
the history and foundation of the relational model from Ted 
Codd's original research to the relational based SQL and 
QUEL systems that are today's industry standards. These 
relational systems will be shown to be inadequate for the 
entire audience of database users. To that end, a graphics 
interface to the relational model will be proposed to 
eliminate relational limitations and deficiencies. 
3. Object Oriented Languages For Graphics Interfaces 
In Chapter III, object oriented concepts will be 
discussed. Languages that are based on these concepts are 
particularly well suited for implementing graphics inter- 


faces. The language for implementing these systems, ACTOR, 
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will be discussed and analyzed in this chapter and subse- 
quent chapters. 
4. The Query Window 
The query window will be presented in Chapter IV as 
the principle interface to the user. A wide variety of 
queries shall be presented and correlations will be shown to 
the SQL syntax of the relational system. In addition 
correspondence between GLAD queries with non-atomic data 
types will be discussed. 
5. Syntax For The GLAD Schema 
In Chapter V, the syntax for the GLAD schema will be 
defined. In addition, correlations between the GLAD, 
extended SQL and SQL schema will be shown. The example 
UNIVERSITY database, presented in Wu [Ref. l:pp. 1-10], will 
be used to illustrate the definition of the GLAD schema. 
The major objects and sub-objects of the UNIVERSITY database 
illustrate both complex and simple data types. 
6. Data Structures To Support The Interfaces 
In Chapter VI, data structures to support the GLAD 
interfaces will be defined. The Collection is the GLAD 
class that will be utilized to form all of the database 
objects. Various descendants of the collection class, such 
as KeyedCollection, Set, Array and Dictionary, will be 
utilized to represent entities, attributes and query 


collections. 
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Jee RLoOrichms For The Translation 
In Chapter VII, algorithms for the translation of 


the GLAD query collections to relational format will be 
presented. These algorithms will be explained in detail 
with example queries to show the translation scheme. in 
addition, a simulator for object translation was constructed 
to show possible translations of queries. Pascal code for 
the simulator is located in Appendix A with output located 
in Appendix B. 
eee Conclusion 

A brief conclusion shall reemphasize the major 
points of this thesis. Potential future applications of 
GLAD will be discussed with an emphasis on military applica- 
tions. In particular, the naive user will benefit greatly 


from learning database concepts with GLAD. 


LS 


Il. THE NEED FOR _AN_INTEREACE UAND EATENSION 


If the relational database systems were entirely 
suitable for the entire audience of database users there 
would be no need for various interfaces to and extensions of 
the relational model. The standard relational systems are 
generally adequate for trained, casual and experienced, 
sophisticated users. But for the naive user, it is 
untenable. Since many users can be categorized as naive 
users, system designers should consider the naive users' 
lack of database background and training when devising the 
syntax and semantics of the database system. Unfortunately, 
many system designs gave little consideration to the novice 
user. 

Recent advances in computer technology have made data- 
base technology available to a wide spectrum of organiza- 
tions, institutions, and businesses. The demand for 
database technology has drastically increased as various 
organizations assimilate computer technology and replace old 
manual, automated and batch oriented systems with 
sophisticated on-line database systems. Systems that 
require the smallest amount of overhead costs and time for 
training will become the new industry standards. 

The history and evolution of the relational model 


provides insight into the limitations and deficiencies of 
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the model. In addition, the relational model can serve as a 
viable foundation for building higher level, database 
abscractions. An analysis of the relational model shall 
confirm the need for a powerful, user friendly interface to 
the relational model. The interface should have semantic 
Capabilities that basic systems do not possess and provide 
easy to use and learn data access, data definition and data 


manipulation features. 


A. A HISTORY OF THE RELATIONAL MODEL 

Database management systems have evolved from simple 
collections of flat files to complex data base models. 
These models are utilized by the sophisticated products that 
are today's industry standards. A significant advance in 
database technology has been attributed to Dr. E.F. Codd. 
While working at the IBM San Jose Research Laboratory, Codd 
wrote his classic paper, A Relational Model for Large Shared 
Data _ Banks. This paper, Codd [Ref.5:p. 1], was the basis 
for the unified set of theoretical ideas that became the 
relational model. While reflecting on the recent history of 
database development, Chris Date, a former database resear- 
cher who worked with Dr. Codd, wrote that prior to the 
development of the relational model, database models lacked 
solid principles and well-defined terminology. Pres Codd 
added mathematical rigor to his database model to validate 


his ideas [Ref. 6:p. 99]. 
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1. Relational Products 

The relational model has received wide spread 
acceptance and acclaim. The simplicity and the uniformity 
of the relational data model has contributed to its popular- 
ity. Successful commercial relational database systems have 
been developed. Some of the successful relational products 
are listed below: 

1. IBM DB2 utilizes IBM hardware and IBM MVS software. 


oe IBM SQL/DS utilizes IBM hardware and IBM VM & DOS 
software. 


a IBM QMF serves as a front-end for DB2 or SQL\DS, and 
uses Fujitsu OS IV F4 software. 


In fact, most of the current systems are in some way 
based upon the relational concept. Furthermore, many 
prototype and research systems are actually utilizing, based 
on, related to or extending the relational model. Some of 
these systems are as follows: 


1. Interface for Semantic Information System (ISIS) is an 
experimental system for graphically manipulating a 
database. ISIS is based on a Simply specified high- 
level semantic data model. [Ret. 72bpp. 328-342) 


2. Gambit is an interactive database design tool for data 
structures, integrity constraints and transactions. 
It supports the definition of static data structures 
in terms of the extended relational model. [Ref. 8: 
pp. 399-407] 


3. An Intelligent Database System for End Users (AIDE/AI- 
DE-II) provides a user friendly and an easy to use 
query language called AQL. [Ref. 9 ipp. 25-30; Rea 
LOt pp. 24-47) 


4. Graphics Language for Accessing Database (GLAD). Ie 
is a unified interface method for interacting with a 
database. It is currently being built on top of a SQL 
based relational model. [Ref. l:pp. 1-11] 
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B PITFALLS AND DRAWBACKS OF THE RELATIONAL MODEL 
Even though the relational database model has changed 
and revolutionized database ‘tschnology, it is not without 
pitfalls and drawbacks. A bad relational database design 
can have significant problems. As addressed in Korth [Ref. 
ll:pp. 173-181], the most serious problems are as follows: 
1. The Repetition of Information. 
2. The Inability to Represent Certain Information. 
3. The Loss of Information. 
1. Redundant and Repetitious Information 
Repetition of information not only wastes valuable 
storage space but also complicates database update. Simple 
changes to a relational scheme can have a large impact on 
the database. The addition of new tuples to the database 
can cause problems. In some instances, repetitive informa- 
tion will be needed for the new tuple to preserve the 
validity of the table. These additions and updates can be 
costly. 
2. Certain Types of Information Cannot be Represented 
Inability to represent certain information can occur 
during the database update. A problem occurs when a tuple 
must be added to a table, and the table does not possess 
values for all of the attributes that are represented in the 
table. The representation of an attribute without value is 
not easily solved. A method for representing nothing or 


null values must be utilized. In addition to the difficulty 
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of determining what symbol shall designate the null value, 
the system implementation of null value attributes is not a 
trivial task. 
3. The Lossy Decomposition 

Loss of information can occur when relational 
schemas with many attributes are decomposed into many 
schemes with fewer attributes. More tuples but less 
information are obtained because many of the new tuples 
contain erroneous information. When the new tuples contain 
erroneous information, we have actually lost information and 
do not have access to the information that was stored in the 
old tuples that were decomposed. This situation is called a 
lossy decomposition. 

4. User Created Database 

From the above mentioned problems, it is easy to en- 
counter problems with database design. An obvious cure for 
the problem is not allowing database users to create their 
own databases. Management shall require that all database 
definition and creation be accomplished by database profes- 
Sionals of the organizational, information systems or data 
processing department. This cure may be acceptable for a 
highly structured organization with a centralized data 
processing environment. However, it will not suffice for an 
organization that has a decentralized data processing 
department, encourages the use of computer technology, makes 


personal computers available to many employees, and gives 
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the workers a great deal of flexibility and latitude in 
using this technology. For this type of organization, the 
solution centers on giving these people the tools to 
accomplish good database design and definition while 
avoiding the common relational pitfalls. It appears that 
basic relational systems are totaily inadequate in this 


regard. 


C. SEMANTIC LIMITATIONS OF THE RELATIONAL MODEL 
Perhaps the most serious limitation of the relational 

model is the inability to express complex real world 
relationships. The inability to handle complex relation- 
ships is defined in Tsur [Ref. 12:pp. 286-295] as semantic 
scantiness. In Date [Ref.6:p. 609], this limitation is 
discussed in detail. Date writes: 

At the time of this writing (1983), most database systems 

relational or otherwise really have only a very limited 

understanding of what the data in the database means: 

They typically "understand" certain simple atomic data 

values, and certain many-to-one relationships among those 


values, but very little else (any more sophisticated 
interpretation is left to the human user). 


1. Poor Semantic Capability 
The relational database model's lack of semantic 
capability precludes this model from completely expressing 
the natural relationships and mutual constraints that exist 
between entities in the database. [Ref. 12:pp. 286-295] 
For real world entities to be expressed as complex 
non-atomic types, cumbersome and indirect methods must be 


utilized. For example, postal worker could not be directly 


2d 


represented in the database as a type of or member of the 
set of government employees. The Relational Model does not 
allow direct representation of these complex types of data. 
Only atomic types such as characters, integers and reals can 
be directly represented in tables. 
2. Semantic Deficiencies and Real World Situations 

Although the relational model is very popular and in 
many ways has revolutionized database technology, it not 
only has serious design pitfalls but also is unable to 
handle many real world situations. We must develop a better 
approach to database modeling and design that can solve the 


above mentioned problems. 


D. ALTERNATIVES FOR IMPROVING THE RELATIONAL LIMITATIONS 

There are many specific approaches that can be utilized 
to improve the limitations and pitfalls of the basic 
relational database system. However, these approaches can 
be classified into two groups. Database designers have the 
following two basic alternatives for improving the relation- 
al model: 


1. The relational model could be abandoned, and a new 
system could be designed and based on a new model. 


2. The relational model could be extended with new 
semantic capabilities added to existing systems. 


1. The Construction of a New System 
The construction of a new system based on a new 
model is a monumental task. Developing the architecture, 


commands and query language takes considerable effort and 
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time. Putting the new system into production requires 
arduous debugging, testing and numerous’ iterations. 
Developing the new system could be costly and unfruitful. 
2. Adding Additional Features to Existing Systems 

The other alternative, adding capabilities to an 
existing relational system, may be a faster and more 
effective way to develop a database system. With this 
approach, capabilities could be added to systems with a 
solid theoretical and functional base. Much of the dif- 
ficulty associated with the system design and development 
process would be entirely avoided. Advantages of this 
approach include capitalizing on existing technology and 
saving development costs that are associated with designing 
new machines, backends and components. The new system, with 
the additional capabilities, can be built on top of a 
functional relational database system. The new system shall 
be a combination or synthesis of the basic model and higher 


level interface. 


E. EXTENDING THE RELATIONAL SYSTEM 

Consider the two following approaches that database 
designers have utilized to extend the capabilities of the 
relational system: 


1. A modified query language approach that offers 
enriched semantic and simplified syntax. 


2. An object oriented approach that provides easy to use 


graphical interfaces and rich semantic features for 
the database user. 
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1. Extension Through Semantic Models 


To understand the rationale for the first approach, 
we must examine the concept of a semantic data model. 
Consider the Entity-Relationship (E/R) semantic model 
proposed in Chen [Ref. 13:pp. 1-10]. The E/R model can 
conceptually be thought of as a thin layer or an extension 
sitting on top of the relational model. An entity is a 
distinguishable object of some particular type or a thing 
which can be distinctly identified. An E/R relationship is 
merely a one-to-one, many-to-one or many-to-many association 
between the entities. 

2. Advantages and Shortcomings 

The advantage of this approach is that it provides a 
built-in set of integrity rules to the user so he does not 
have to explicitly formulate certain foreign key rules. 
Foreign key rules are implicitly understood by the system 
when the user specifies the type of the relationship as 
Many~to-one, one-to-one or many-to-many. Although these 
concepts are powerful, they are not well-defined and left 
open to a designer's interpretation. 

3. A Step in the Right Direction 

Chen's model has enjoyed great success as a design 
tool. However, a successful implementation of the E/R Model 
has not been accomplished. Perhaps this is due to the E/R 
model's lack of precisely defined terms. Nevertheless, 


these ideas form powerful concepts that can be used to 
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improve the relational model by making it easier to under- 
stand. Understanding is enhanced by adding enriched 
semantic features and simpler syntax to the basic relational 


model. 


F. BASIC RELATIONAL SYSTEMS ARE DIFFICULT TO LEARN AND USE 
It is not surprising that many of the current relational 
database products are conceptually very difficult for users 
to learn and understand. Even with simple data base opera- 
tions, a user may not understand how to formulate a query to 
access the database. Analysis of primitive relational 
constructs validates the need for a natural presentation of 
the data to the user in an easy to understand manner. 
1. Deficiencies with Relational Based Systems 

Most database users do not have adequate math and 
computer science backgrounds to effectively understand and 
efficiently use the full range of primitive. relational 
constructs. Two of the most widely used relational query 
languages, SQL and QUEL, are based on relational algebra and 
tuple calculus. Even though the design details and imple- 
mentation of the data model are shielded from the user, he 
will need to understand certain types of math-like con- 
structs that are related to the representation of data that 
is stored as tuples in tables. 

Consider the complex SQL query contained in Date 


[Ref. 14:pp. 76-77] and shown in Figure 1. 


AS 


Select supplier names for suppliers such that there does 
not exist a part that they do not supply. 
SELECT SUPPLIER NAME 
FROM SUPPLIER 
WHERE NOT EXISTS 
(SELECT * 
FROM PARTS 
WHERE NOT EXISTS 
(SELECT * 
FROM SHIPMENTS 
WHERE SUPPLIER_NO# = SUPPLIER.SUP- 
PLIER_NO# 
AND PART NO# = PARTS.PART NO#)); 


Figure 1. Complex SQL Query 


To formulate this query the user must have extensive 
knowledge of many different math and computer concepts. In 
addition, it must be noted that the above method is not the 
only way to formulate the query to retrieve the supplier 
names. Even though the above query is the most literal 
interpretation of the request, there are numerous ways to 
formulate this complex query. This situation can be 
overwhelming to the inexperienced user. For example, 
consider the following nested query contained in Date 
(Ref.14:pp. 67-68], observe the differences in query 
constructs, and determine which query is the easiest to use 
for 'Get supplier names for suppliers who supply part P2': 

i. SELECT SUPPLIER NAME 
FROM SUPPLIER 
WHERE SUPPLIER _NO# IN 
( SELECT SUPPLIER INO? 


FROM SHIPMENTS 
WHERE PART NO# = P2); 
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a. SELECT SSsuPPLIER NAME 


FROM SUPPLIER 
WHERE SUPPLIER_NO# IN 
( §Sig, Asa pase ee See 
3. SELECT SUPPLIER.SUPPLIER_NAME 
FROM SUPPLIER, SHIPMENTS 


WHERE SUPPLIER.SUPPLIER_NO# = 
SHIPMENT.SUPPLIER_ NO# 

AND SHIPMENT. PART _NO# = 'P2'; 

Which of the above queries is easiest to formulate? 
The first query requires the user to understand the use of 
nested selects. The second query requires the use of set 
theory and explicit knowledge of suppliers who supply part 
P2. The user may not have this knowledge. The third query 
requires use of table joins and dot notation. In addition, 
there are many more methods for formulating a query for 
suppliers that supply part P2. The user must make many 
decisions to formulate a SQL query. The user's choice will 
depend on his background and preference. 

2. Too Much is Expected From the User 

Perhaps too much is expected from the user in query 

formation. For the example queries, we have required 


knowledge of the following: 


1. Table joins on specific attribute conditions. 


2. Dot notation used with joins of a relation. 

3. Order of precedence of the query operators 
(i.e., nested selects). 

4. Syntax of the language. Terms and meanings. 
(I.e., from, where, select, and not.) 

5. Logical operations and meanings. Existential 


quantifiers and negation. 
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3. Difficulties in Translating the Requirement 


The difficulties in understanding the syntax and 
semantics are not the only problems the user will have in 
formulating a query. Perhaps the greatest problem is the 
translation of the query requirement from the domain of 
plain English to set type constructs. The human mind does 
easily translate a plain English requirement to set type 
structures because the mind simply does not reason and think 
in set type constructs. Humans tend to reason in both 
simple and complex conditional statements that are analogous 
to if then else type statements. Translating the require- 
ment to set type syntax, that will obtain a range of answers 
from specified domains, will not generally be trivial for 
naive users. 

4. Substantial Training Is Required 

The user is required to learn and understand a 
significant amount of information to access the database. 
In summary, this approach is acceptable for sophisticated 
users and computer professionals, but it will undoubtedly 
present problems to naive users that lack formal backgrounds 
in math and computer science. A substantial amount of 


training is required to use these systems. 


G. RELATIONAL QUERY LANGUAGES MUST BE IMPROVED 
In Wong (Ref. 15:pp. 22-23], the following factors are 


discussed and given as reasons for user difficulty in 
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learning, understanding and using the standard query 
languages: 


1. The user is forced to remember too many things. The 
user is required to remember attribute names, attri- 
bute formats, record types and values. In addition, 
the user must remember the meaning of certain reserve 
words that will be used in query formulation. 


2. Standard query languages support semantically poor 
data models. Query languages that are based upon 
solid mathematical principles such as tuple calculus 
and relational algebra are difficult for non math 
oriented users. A user that has not had formal ed- 
ucation in calculus, logic, discreet mathematics 
and set theory will not be able to understand the 
finer points and implicit assumptions that exist 
within the relational model. 


3. There is no feedback during the query process. 
Users generally do not formulate a correct query on 
their first attempt. Logical mistakes with queries 
can be very subtle and hidden to even sophisticated 
and experienced users. A query language should have 
features for building a complex query in a piece 
meal, interactive fashion. Such features would make 
the formulation of a difficult query, such as example 
one, a much easier task. With feedback on partial 
results, the completed query would be correct. 


4. Lack of levels of detail in schemas. Ina large data 
base hundreds of attributes may be stored. It is very 
difficult for the user to select relevant attributes 
for a query when he must review a very large potential 
set of attributes for query. There is no mechanism 
available to control the amount of detail that is pre- 
sented to the user during query formulation. 


5. Lack of meta-data browsing facility. The user needs 
a facility to browse the meta-data to obtain a general 
overview of the database. 
Friendlier query languages must be provided to the 
user to access the database. Simplifying the syntax of the 


query is important for extending the usability of the 


relational model. 
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H. GEM AS AN EXTENSION OF THE RELATIONAL MODEL 
The GEM semantic data model, Tsur [Ref. 12:p. 286], is 

implemented on a dedicated backend and remedies semantic 
scantiness by supporting features that the relational model 
does not provide. Zaniola and Tsur describe their DBMS as 
consisting of a user-friendly front-end supporting the GEM 
semantic model and query language under the UNIX time- 
sharing system. In addition, they utilize a dedicated back- 
end processor to provide concurrency control, recovery and 
support for all database transactions. A high level diagram 
of the model is contained in Figure 1. GEM provides the 
following extensions to the relational model: 

1. Notions of entities with surrogates. 

2. Aggregation and generalization are supported. 

3. Null values and set valued attributes. 


4. GEM has extended the basic QUEL language to handle 
the new constructs. 


1. Semantic Scantiness and User Friendliness 

The system designers of this GEM implementation have 
not only tried to remedy the semantic scantiness of the 
basic relational model but also have attempted to provide a 
friendlier query language for the user. They have capital- 
ized on the good features of the relational model by 
building GEM on top of the relational model and have 
eliminated the relational limitations with the more powerful 
GEM model. Furthermore, this system also improves recovery 


and performance issues of the basic INGRES system. 
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2. Simplified Syntax of the GEM Implementation 
However, the simplified syntax seems to fall short 
of truly improving the difficulties associated with making a 
relational query. This GEM extension to QUEL still seems to 
be unsuitable for users with little computer science or math 
background. The GEM queries have potentially simplified the 
QUEL syntax by allowing the user to directly address non- 
atomic data types in the query. Without this feature, at 
least one additional table would be required for the query. 
The length of the query would be increased because either 
nested selects or table joins to indirectly address a non- 
atomic data type would be required. But, even with this 
abstract improvement, the same types of basic problems with 
formulation of queries still exist. For example, consider 
the following example query: 
GEM --> range of E is EMPLOYEE 

retrieve (EMPLOYEE.NAME) 

where EMPLOYEE.DEPARTMENT is 

E.DEPARTMENT and E.NAME = "J.Black"; 

The user is required to be familiar with ranges, 

attributes and conditions. These constructs can provide a 
considerable challenge in formulating a complex query. The 
user must understand the logical operations. Furthermore, 
he must become proficient with tuple calculus to master the 
GEM extension. It would seem that the goal of supplying a 
user friendly interface to naive users is not accomplished. 
The syntax is still basic QUEL syntax that allows the direct 


expression of certain non-atomic data types. The GEM model 
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may be untenable for unsophisticated and inexperienced 
users. 

Many other semantic data models that have been 
developed to extend the relational model have similar 
strengths and failures of the GEM model. However, none of 
the models that have been implemented with the first 
approach, semantic extension with a simplified query 
language, are both powerful and friendly. These models are 
generally implemented with a conventional high-level 
language (procedural) and accessed with a set oriented (non- 
procedural language). These types of languages are not well 
suited for providing powerful features and user friendly 


interfaces to the relational model. 


I. VALIDATION OF THE NEED FOR A BETTER INTERFACE 

Systems that utilize standard query languages as an end 
user interface are limited in both capability and potential 
use. SEQUEL and QUEL are clearly not the best choices for 
an end user interface to the database. However, these 
standard query languages have potential to aid a higher 
level interface to data that is stored in a relational 
backend. 

The graphics interface of GLAD will add an additional 
layer of higher level abstraction to the data base system. 
It is possible to obtain more meaningful representations of 
entities as database objects instead of tables of attribute 


names and values. Finally, the expression of complex data 
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types as sub-objects will provide a realistic view of the 
data base. The mutually supporting goals of supplying both 
a friendly user interface and a powerful semantic extension 


Small be realized with GLAD. 


ANS 


ITI. OBJECT ORIENTED LANGUAGES AND GRAPHICS INTERFACES 


Object oriented programming languages, such as 
Smal iTalk-80 and ACTOR, offer an attractive alternative to 
the conventional approach of developing a semantic data 
model. A distinct advantage of the object oriented approach 
is an object oriented programming language's integration of 
active programming instructions with passive data. In a 
conventional, high level programming language, such as C or 
pascal, data is separated from the control structures, and 
operations are performed on the data by procedures and 
functions. Since object oriented languages do not separate 
the data and control structures, the data and instructions 
are integrated into a self-contained unit called an object. 
The objects themselves become active elements in program 
execution because the code to do things such as_ sort, 
divide, square root and print is actually part of the 
object. An object has the capability to perform operations. 
The object performs an operation when it receives a message. 
A program is executed by an object sending messages to other 
objects. The operation is performed by the object utilizing 
a method it contains or inherits from one of its ancestors. 
Just as we inherit traits and characteristics from our 
parents and ancestors, an object inherits methods from its 


parents and ancestors. If a method is in an object's class 
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hierarchy or family, the object is able to utilize the 
method. (Ret y'4 spp.) 1-50] 

Object oriented languages, such as ACTOR, possess 
powerful graphical capabilities. These graphical 
capabilities can be used to present data to the user in a 
manner that best represents a high level abstract view of 
the individual data entities and the relationships that 
exist between these entities. Pictorial objects can be 
Peay accessed and tailored for any specific database. 
Basic graphics objects of the object oriented language are 


general enough to be used for many different applications. 


A. OBJECT ORIENTED REPRESENTATION OF THE DATABASE MODEL 
Object oriented languages seem to be particularly well 
suited for implementing database models. The use of objects 
to represent real world information is clearly superior to 
the conventional approach of data base modeling. The 
conventional approach attempts to represent real world 
entities as tables that contain tuples of data. 
1. Database Objects Modeled For Real World Entities 
Real world entities, such as student, professor and 
employee, have the ability to perform certain tasks. 
Objects modeled to represent the real world = student, 
professor and employee can be given methods to perform 
operations. These operations represent real world tasks. 
For example, suppose the chairman of the computer science 


department tells his secretary to sort all of her student 
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files in ascending alphabetical order. The secretary 
receives the instructions and sorts the student files by 
utilizing a simple method that she has developed in the 
offices After she accomplishes the task, she informs the 
chairman that she has finished sorting the student files. 
2. Modeling the Objects 
The database objects perform in a similar manner to 
the real world entities that the objects represent. In 
addition, the chairman could send the same message to many 
different objects, and each of the objects could perform the 
request in a different way. This is similar to the chairman 
giving two secretaries the same instructions. Each of the 
secretaries perform the instructions in a different way 
according to the method that each of the secretaries has 
learned or developed. This ability is a form of polymor- 
phism, the property of having, assuming or passing through 
various forms and stages. It is a powerful concept because 
it closely parallels the way the human mind functions and 
thinks. —(Refa4@:o. 33] 
3. Objects That are Easy to Use and Learn 
The object oriented model can be constructed for 
ease of use and learning. The primary objective of this 
approach is to eliminate user associated difficulties with 
conventional query languages like QUEL and SQL. Users can 
be given a data model that can be directly manipulated. 


They shall be able to gather information and access data 
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mech a minimum amount of difficulty. This approach will 
make database usage available to a very wide audience. 


foo. |: pp. 1-11] 


B. THE INTERFACE FOR ACCESSING DATABASE 

GLAD shall be implemented with an object oriented 
programming language called ACTOR. This language was 
developed by the White-water Group, Incorporated. ACTOR 


possesses powerful features that will be realized by using 


the Microsoft Windows environment. The White Water Group 
claims: 
There are many benefits to this approach,...object 


oriented programming makes it easier to develop, change, 
and debug advanced programs. Actor is a complete pro- 
gramming environment. It uses all the power of Micro- 
soft Windows (MS-WINDOWS) to help you organize and 
analyze your work. So you can see all of your work at 
the same time and trace the influence of one part on 
another as you make changes. This makes programming 

in Actor a fluid, natural extension of the way you 
think--entirely unlike conventional programming. 

Beet. 4:p. 25] 


1. Easy to Use and Learn 
Through implementation with ACTOR, GLAD will achieve 
the important objective of being both easy to use and easy 
to learn. GLAD will be a unique approach to utilizing 
graphical information to represent real world entities. 
With the Microsoft Windows programming environment, entire 
objects will be as easily manipulated by the user as simple 


atomic data types. 
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2. Coherent Interaction Method 

In addition, ACTOR will be utilized to provide GLAD 
with a coherent interaction method for data manipulation and 
program development. Although GLAD is not based on a 
specific data model, it can be used to extend a specific 
model's capabilities. It possesses tremendous potential for 
improving a current relational system's capabilities and 
providing the user with a friendly graphics interfaces. 
Other visual models are based upon specific models and are 
therefore limited in capability, portability and potential 
use. GLAD combines the best features of higher level data 
base abstractions from many of the other data models. In 
addition, GLAD provides an efficient and effective means for 
interacting with the database through data definition 
interaction, data manipulation interaction and program 
development interaction. ACTOR is the ideal language for 


developing this type of interactive environment. 
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ieee ae OUBRY WINDOW 


The most important window interface to the user is the 
query window. The query window is the most frequently 
employed user interface for accessing information stored in 
the database. A result window is automatically activated by 
the query window to show the user the information that was 
accessed and retrieved. Since the information is actually 
retrieved from a relational backend, it is necessary to 
understand the high level correspondence between the GLAD 
window interface and the relational SQL query. Therefore, 
the correlations between the major types of user windows to 
SQL queries shall be shown. The window queries are based on 
the sample relational queries that are contained in a 
pedagogical database that was utilized in Date [Ref. 14:pp. 
os 0 || . Accordingly, the relational syntax for the DB2 
system is standard SQL and will be utilized in conjunction 


with the GLAD queries. 


A. GLAD TO SQL 

The GLAD window is able to eliminate most relational 
type constructs from the user query. Essentially, a 
translation from the GLAD object oriented query to the set 
oriented SQL query must be accomplished. Before the transla- 


tion algorithm is discussed, an in-depth examination of 
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possible user queries shall be conducted, and GLAD to SQL 
query correlations will be reviewed. 
1. Simple Queries 
A few simple examples will be utilized to explain 
the simple query. The simplest queries are of the following 
SQOLMEorm: 
- SELECT designated fields 
- FROM a designated table 
- WHERE a designated condition is met or true. 
The GLAD query window is selected by the mouse and 
opened for query on the display screen. Figure 2 shows the 


basic GLAD query window. 


[GLAD QUERY] 


OBJNAME QUERY 


OBJNAME 






SUBOBJ 


SUBOBJ 







SUBOBJ 





Figure 2. The GLAD General Form Query Window 


After the query window is opened, instructions can 
be typed next to the OBJNAME, * or SUBOBJ's. The window 


items will be used in the following manner: 
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1. OBJNAME can be used for object instructions. 


2.  * can be used for aggregate operations and 
formulation of nested selects. 


bee SUBOB! Can be used for retrieval of attribute 
values and forming conditions with relational 
operators. 


a. Simple Query with Condition 
Consider the following query: 
Get supplier numbers and status for suppliers in Paris. 
The GLAD query window and corresponding SQL 


query are shown below in Figure 3. 


[GLAD QUERY] 


SUPPLIER QUERY ans 


SUCPLIER 








[SQL QUERY] 


BoE nee te eUPP NO, slATUS< 





SUPP_NO# 










> FROM SUPPLIERS 


SlALUS 
> WHERE Clee 2 PA 1S a. 
CIE 


SNAME 


Figure 3. Simple Query with Condition 


With this simple query, it is easy to correlate 
the GLAD query entries to the SQL query lines. The GLAD 


query window for the SUPPLIER object was previously selected 
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and can be correlated to the FROM line in the SQL query. 
The SUPPLIER object is analogous to the SUPPLIERS table of 
the relational data base. Therefore, the selection of the 
SUPPLIERS query can automatically be substituted in the FROM 
line of the SQL query. The '.P', next to the attributes or 
sub-objects, SUPP_NO# and STATUS respectively, designates 
the SELECT line attributes. The user can think of '.P' as 
being analogous to a print command. Essentially, the system 
is instructed to print the sub-object values that satisfy 
the query. Finally, the " = 'Paris' " specifies the 
condition that must be met for the '.P' sub-objects to be 
retrieved. The CITY sub-object must be equal to the string 
value 'Paris'. Ultimately, attribute values for SUPP NO# 
and STATUS will be retrieved from a tuple that has an 
attribute value of ‘Paris’ for, Che cfr, aterieuce. 
b. Simple Query without Condition 
A simple query may be formulated without a 
qualification. Essentially, the system is instructed to 
retrieve the specified sub-object or sub-objects from a 
designated object. Consider the following example query: 
Get the part numbers for all parts that are supplied. 
The GLAD query window and corresponding SQL 
query are shown below in Figure 4. The user must be aware 
that every part number will be retrieved since no qualifica- 
tion is used. In addition, redundant entries in the data- 


base will not be eliminated with this type of retrieval. 
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{GLAD QUERY] 


| SHIPMENT QUERY ———4 


| SHIPMENT | ' 









(SQL QUERY] 







> SELECT PART_NO# 
SHIP_NO# 






'——> FROM SHIPMENT 
PART _NO# 






QUANTITY 





Migures4= Simple Query without Condition 


Gu Retrieval with lupltecate Elimination 
The above-mentioned problem can be eliminated by 
directing the system to eliminate duplicate items. Consider 
the following example query with duplicate elimination: 
Get the part numbers for all parts supplied, with 
redundant duplicates eliminated 
The GLAD query window and corresponding SQL 
query are shown below in Figure 52 
The redundant elements have been eliminated by 
specifying that the '.P' operation be done in a DISTINCT 
manner. Duplicate entries have been eliminated. But 
additional syntax, that must be understood by the user has 
been added to query. If eliminating the duplicates is 
important to the user, the trade-off of adding syntax to 


eliminate duplicates will be equitable. 
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[GLADS OUERY | 





SEL PMENTSCUER 






SHIPMENT, 







(SQL QUERY] 


>SELECT DISTINCT PART NO@ 





SHIP_NO# 






SHIPMENT 
PART _NO# 






QUANTITY 





Figure 5. Simple Query with Distinct Ordering 


2. Retrieval Using Computed Values 


Simple arithmetic operations can be performed on 
selected sub-objects that have been designated for retriev- 
al. GLAD shall allow addition, subtraction, multiplication 
and division to be performed on queried sub-objects to 
obtain certain types of numerical conversions. Conversions 
from pounds to grams is an example of a numerical conversion 
that can be accomplished. 

a. Retrieval with Multiplication Operator 

Retrieving a sub-object that is modified by an 
arithmetic operation is a simple task. Consider the 
following query that utilizes an addition operator: 

Get the weight in grams (stored in pounds) from PARTS that 
are located in Paris. The GLAD and SQL queries are listed 


below in Figure 6. 
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[GLAD QUERY] 





PAR oD OUERY 










ZOLOR 





Pee ROM PARTS 
WEIGHT 







> WHERE CTTyY = 
Paris. 







ay 






PNAME 


Figure 6. Retrieval with Arithmetic Operation 


This arithmetic operation is easily accomplished 
by typing the arithmetic operator and operand immediately 
after the '.P' retrieval designator. 

b. Retrieval with Addition Operator 

Retrieval with an addition operator is handled 
the same way that the above multiplication operator is 
Meamaied. The syntax is '.P + Number’. 

c. Retrieval with Subtraction Operator 

Retrieval with a subtraction operator is 
analogous to the retrievals that have been discussed. The 
user must take greater care in using the subtraction 
Operator because the range of numbers allowable for database 
representation must be considered. The syntax is '.P- 


Number'. 
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d. Retrieval with Division Operator 

Retrieval with a division operator is similar to 
the multiplication, addition and subtraction retrievals. 
Again, the user must take care in using the division 
operator not only because of the range of allowable numbers 
but also because of gross potential error problems such as 
division by zero. The syntax is '.P / Number', and Number 
must be <> QO. 

e. Use of Strings with Aggregate Operations 

Additional flavor can be added to a query by 
specifying a message to be returned with the query results. 
It is possible to convert a weight that is stored in pounds 
to grams and describe this conversion with the returned 
results. Figure 7 shows how a message may be ordered. The 
2 in front of the string, 'Weight in grams', indicates that 
the string message will be mapped to the second item in the 
SQL SELECT line. 

It is anticipated that the results of ee query 
will be returned to the user in the GLAD results window. 
Figure 8 shows a possible representation of these returned 
results. 

The query contained in Figure 8 represents one 
way to use a message. Messages can be individually tailored 
for specific queries. They do not have to be limited to use 
with aggregate operations. In addition, messages can be 


inserted anywhere in the SELECT line by explicitly 
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PARTS QUERY ae | 


PARTS 2 ‘Weight in grams’ | 
: | 
COLOR 
PNAME ae 
Clr 
WEIGHT ~Pe* 454 
V V | V 


SELECT PNAME, ‘Weight in grams’, WEIGHT * 454 





FROM PARIS < 


Figure 7. Query with a Message 


RESULTS 


PNAME MESSAGE WEIGHT 





Figure 8. Results with a Message 


designated position of 2, 3 or any desired position. 1036 
explicit ordering is not designated, the system translation 


will default to position one. 
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3. Print All Sub-Objects of an Object 


A very desirable query feature is the ability to 
print out all the sub-object attribute values contained in 
an object with out explicitly selecting all sub-objects with 
',P' operations. This ability is analogous to the SQL query 
where the entire table is copied. 

Consider the following query: 

List all the sub-object values of the SUPPLIER object. 

The GLAD query and corresponding SQL query are 


listed below in Figure 9. 


[GLAD QUERY] 







SUPPLIER GUERY 


SUPPLIER 
[SQL QUERY] 


Peover 









SUPP_NO# 
> FROM SUPPLIER 
STATUS 
CIry 


NAME 
Figure 9. Copy the Entire Table 

The '*' is used to represent the retrieval of all 

sub-objects in the designated GLAD objects. The '*!Samn 

GLAD is directly correlated to the 'SELECT *' in SQL which 


directs the system to produce an entire copy of the table. 
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Using the '*' for retrieval is a shorthand method of copying 
the entire table by explicitly doing a '.P' operation on 
every sub-object. 
4. Qualified Retrieval With More Than One Condition 

The user may place further restrictions or qualifi- 
cations on a GLAD object by using relational operators on 
more than one sub-object in the query. Consider our first 
query, but, with an additional restriction that the status 
must be greater than 20. The first query is modified as 
follows: 


Get the supplier numbers for suppliers in Paris that 
have a supply status greater than twenty. 


The GLAD query and corresponding SQL query show the 
correlation of the GLAD query to the SQL constructs. The 
second condition is simply represented by 'AND' which is 
used to form the conjunction of the conditional statements. 
The query in Figure 10 has more than one condition to 
illustrate the ability of GLAD to form conjunctions with 
multiple conditions. 

The only difference between this retrieval and the 
Simple retrieval is the mapping of successive conditions to 
‘AND! for conjunction with other SQL statements. 

5. Retrieval with Ordering 

The user may wish to guarantee that the retrieved 
information be returned in either descending or ascending 
order. This ordering can be explicitly specified in the 


query. Generally, the retrieved information is not 
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{GLAD QUERY } 






SUPPLIER QUERY 


SUPP RLER 





[SQL QUERY ] 


Vv 


SELECT SUPP_NO# 
SUPP_NO# 






> FROM SUPPEUER 
STATUS 







> WHERE STATUS > 9205 







Clix 
> AND CITY = "Paiamcr 


NAME 






Figure 10. Retrieval with Conjunction of Conditions 


guaranteed to be in any particular order. Order in either 
ASC (ascending order) or DESC (descending order) can be 
specified. 

Consider the following query requirement: 


Get the supplier numbers and status for suppliers in 
Paris, in descending order of status. 


The GLAD query window and corresponding SQL query 
are shown in Figure 11. 

The compact GLAD query must be translated to the 
more complicated SQL query. The '.P' and "DESC' operatue 
on the status attribute must be translated from the GLAD 


query to both the SELECT and ORDER lines in the SQL query. 
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[GLAD QUERY] 





SUPPLIER QUERY 








SUPPLIER 
(SQL QUERY] 


> SELECT STATUS 
SUPP_NO# 






> FROM SUPPER 







STATUS 
> WHERE ClTY -=98 Paris” 







erry 
> ORDER By “STATUS DESC 


SNAME 





Figure 11. Retrieval in Descending Order of Status 


6. Retrieval Using Between 


GLAD will allow the use of retrieval with BETWEEN so 
that a user may specify an explicit range of values for 
retrieval of the designated sub-object. Consider the 
following query requirement: 

Get the parts whose weight is in the range 16 to 19. 

In addition to the above query, consider this query 
requirement: 

Get the parts whose weight is not in the range 16 to 19. 

The first query retrieves all parts whose weight is 
greater than or equal to 16 or less than or equal to 19. 
The second query is the contradiction of the first and 


retrieves values less than 16 and greater than 19. 


ell 


The GLAD and SQL queries are listed below in Figure 


es 


[GLAD QUERY] 





PARTS QUERY 







COLOR 


WEIGHT 








atid 







PNAME 


PARTNO# 




















V 
PNAME, 


Vv V 


SELECT PARTNO#, COLOR, WEIGHT 





[SO QUERY ] FROM PARTS < 


WHERE WEIGHT BETWEEN 165AND 29- < 


Figure 12. Using a Range of Weight Values 


The negation of the above query is accomplished 
simply by changing the last line to the following: 
WHERE WEIGHT NOT BETWEEN 16 AND 19 
7. Retrieval Using IN 
GLAD queries to determine if a sub-object value is 


an element of a user specified set of values can be stated. 


ay 


The definition of the set is dependent on the user query. 
This query can also be thought of as a shorthand method for 
a predicate involving a sequence of individual comparisons 
that are ORed together. PReEE.. 1423p. °50"] 

We shall not encourage the user to utilize the OR 
expression when formulating GLAD queries. The OR expression 
can lead to subtle logic errors. For example, consider the 
following type of query referred to in the above referenced 
literature: 


SELECT PARTNO#, PNAME, COLOR, WEIGHT 


FROM P 

WHERE WEIGHT = 12 
OR WEIGHT = 16 
OR WEIGHT = 17; 


Although we can explicitly allow a GLAD query to 
translate to this SQL format, the same results will be 
obtained through use of the below listed query shown in 
Egure 13. 

The above GLAD query translates very efficiently to 
SOL. The syntax used in the GLAD query utilizes the 
familiar set type notation, { memberl, member2, member3, 

-}, introduced to most people in elementary school. This 
type of a query is an effective and efficient method of 
obtaining a specific result from a group of alternatives 


that are members of a user defined set. 
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[GLAD QUERY] 


| PARTS QUERY 


PARTS 





COLOR 
WELGH ~P ING 4 D2gee:, 
Chis 
PNAME 


PARTNO# 





V V V V 
SELECT PARTNO#, PNAME, COLOR, WEIGHT 


[SQL QUERY] FROM PARTS << 


WHERE WEIGHT (EN (ee Ge ae, < 


Figure 13. Retrieval Using a Set of Weight Values 


8. Explicit Use of OR for GOuery 


If the user determines that he wants to explicitly 
formulate a query with OR disjunctions, he can format his 
query in the following manner shown in Figure 14. 

Essentially, the default conditions for GLAD specify 
that all conditional statements should be made into a 
conjunctive query. In order to utilize 'OR', the user must 
explicitly designate the use of 'OR' to prevent the transla- 


tion from defaulting to ‘'AND'. 
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[GLAD QUERY] 


PARIS QUERY 


COLOR we 

WEIGHT ~-P =12 OR =16 OR =17 
(ag 

PNAME 


PARTNO# 





V V V V 
SELECT PARTNO#, PNAME, COLOR, WEIGHT 


[SQL QUERY] FROM PARTS <- 
WHERE WEIGHT = 12 < 
OR WEIGHT = 16 < 
OR WEIGHT = 17 < 


Figure 14. Retrieval Using a Set of Weight Values 


Pe SceoOr Okmko Porm a DiSiinection@or Attributes 


A GLAD query can also be formed on the disjunction 
Smeetwo distinct attributes. Consider the query that was 
previously shown in Figure 10. Shown below is the disjunc- 


imeem, Vice conjunction, of the attributes. 


S/S) 


(GLAD QUERY] 


] 
| SUPPLIER | || 
| | ' [SQL QUERY] 
* 
| > SELECT SUPP_NO# 
SUPP_NO# 
L————> FROM SUPPLIER 
STAT > 20) 
> WHERE STATUS =) 20. 
Crry OR = ‘Paris’ 
jeulbess OR CITY = ‘Parise 


NAME 





Figure 15. Disjunctieon ef Attributes 


10. Retrieval Using a Character or String Sequence 


The user may utilize a character or string sequence 
to specify a retrieval. Consider the following query 
requirement: 

Get all parts who's names begin with the letter c. 

Therefore, every part name that begins with a letter 
c should be retrieved by this query. The length of the 
string or value of any subsequent characters in the string 
are irrelevant to the retrieval instructions. 

The query displayed in Figure 16 will retrieve all 
the sub-object values that are contained within the PNAME 
that has C as the first character of the PNAME. The PNAME 
object is mapped to the relational PNAME attribute for 


retrieval, and the instructions on this sub-object are 
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Penis. QUEERS 


COLOR 





WEIGHT 


Cary 


PNAME isa sUcvo. ues Omi 


PARTNO# oe 





V V V V 
SELECT PARTNO#, PNAME, COLOR, WEIGHT 


{SQL QUERY] FROM PARTS os 


WHERE PNAME LIKE ‘C%’;< 


Figure 16. Retrieval Using a Search String 


translated to the 'SELECT PNAME' and 'WHERE PNAME LIKE C&%'! 
portions of the SQL query. 

A GLAD query can be formulated for an embedded 
character string in the following manner as shown in Figure 
BS? 

This query will retrieve all the sub-object values 
designated for retrieval by the .P operation whose PNAME 
value has a ‘'cre' embedded in it. For example, the string 


'screw' would satisfy the query condition. 


oi 


[GLAD QUERY] 


| PARTS QUERY i in 


J 


PARTS 

* 

COLOR os 

WELGHT Pp 

Gury 

PNAME _P HAS ‘*cre*! 

PARTNO# Pp 

V V Vv Vv 
SELECT PARTNO#, PNAME, COLOR, WEIGHT 

{SQL QUERY ] FROM PARTS <= 


WHERE PNAME LIKE Scres “7- 


Figure 17. Retrieval with Embedded Sting 


11. Query with More than One Object 
A powerful feature of GLAD is the ability to utilize 
more than one object for a query. The user can easily 
accomplish this task by opening more than one GLAD query 
window. The user may open a query window for every object 
in the database. Depending on how the query is formulated, 
the GLAD query will either translate to a SQL join or nested 


SELECT Query . 


5S 


i. More than One Obj ect=-Equijoin 


We can retrieve all sub-objects of two tables by 


opening two query windows as shown in Figure 18. 


SUPPEUTER QUERY 


SUPPLIER ae 
{GLAD QUERY] 


[WINDOW 1] 


SUPP_NO# 


STATUS 


CEly = PAS. c ily 


SNAME 





=oeseeCl  SUPPRIER. *, PARTS.* <= 
> FROM PSUPPOIER, PARTS< 


WHERE SUP Poe CiLY y— PARIS. CIVys< 


PARTS QUERY fol OUERY | 


[GLAD QUERY] 
[WINDOW 2] 


COLOR 


WEIGHT 


Ciiey 


PNAME 





Figure 18. Retrieval with Equijoin 
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13. Multiple Objects with Multiple Conditions 


When more than one object query window is opened, 
any number of qualifying conditicns may be specified for the 
GLAD query. The first qualifier is mapped to the WHERE line 
and subsequent conditions are mapped to the AND line of the 
translated SQL query. Any ambiguity with sub-object names, 
such as CITY in both the PARTS and SUPPLIERS objects, is 
resolved by translating the GLAD query with explicit 
specification of object name to table name. A Yana 
divide the object from the attribute, and the sub-object 
name will be translated to the attribute name. Figure 19 
contains and example of this type of query. 

14. Retrieval of Specified Fields from a Join 

Specific fields can be retrieved from a multiple 
object query with the '.P' operations. Any number of sub- 
object fields may be retrieved in this manner. If ambiguity 
exists with sub-object names, the system will resolve the 
ambiguity by using the entire object name with dot notation 
for the translated SQL. 

15. Copy Sub-Objects From Separate Tables 

A copy of all sub-objects that meet specified condi- 
tions can be obtained in an efficient manner. With multiple 
query windows, all sub-object tuples that meet the specified 
conditions can be retrieved by using the shorthand notation, 
'.P' on the '*' for sub-object. Consider the query in 


Figure 19. The result window shall obtain all sub-objects 
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| | 


SUE Erik OuaRY 


SUPPOPER 


SUPP _NO# 












<> 20) 


Soc) Ve clS pg lla i 








a oE LECT SUPPLIER. *, PART og" < 
> FROM ~SUrPOLER, PARTS < 
WHERE SUPE ERIE RAGE INe> PARTS.CI ny >< 


> AND SUPPLIER.STATUS <> 20 


Bento QUERY 


COLOR 


WEIGHT 


Gun 


PNAME 





Pagune 19. Cepy Jcined Tables on Conditions 


from both tables that have ( SUPPLIER.STATUS ee Oe anc 


meacPPLiPR. CITY > PARTSSGETY ). Therefore, the STATUS can 
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be anything but 20, and “SUPPLIER cliy ence alphabetically 
Tollow the PARTS.CITY. 
16. Query With Three Object 
As stated previously, a GLAD query is not limited to 
any specific number of tables. For example, three GLAD 
query object windows can be utilized to make a query. An 


example using three QUERY windows is contained in Figure 20. 







SUPPLIERS QUERY SHIPMENT QUERY 











SUPPLIERS SHIPMENT 
* * 





SUPP_NO# SHIP_NO# 
STATUS PART NO# 
Cris QUANTITY 
SNAME 





| SELECRS SUPPLIER Gti ee ent >. Cit ie 


>» FROM SUPPLIER PARTS ot Le MEN 
















WHERE SUPPLIERVGUlY Seer anise. 6 liye 













AND PART ONG (ae eo) 9, 


wees §=PARTS QUERY 





PARTS. €11y 






Figure 20. Three Object GLAD Query 
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The query contained in Figure 20 has been condensed 
to allow the three object windows and the correspondence to 
the SQL constructs on the same page. 

17. More Than One Object--Nested Select 

GLAD is not entirely limited to translating a 
multiple object query to a SQL query that joins tables. As 
mentioned earlier, the GLAD query may be translated to a SQL 
query that uses nested selects. Consider a query that was 
previously handled by simple joins. The query that gets the 
supplier names for suppliers who supply part 'P2' can also 
be obtained through the use of the existential quantifier. 
Consider the query contained in Figure 21. This query, that 
makes use of the existential quantifier, was originally 
expressed in the following manner: 


Get the supplier names for suppliers who supply 
part 'P2!. 


a. GLAD'S Use of the Existential Quantifier 
The GLAD query that utilizes nested selects is 
expressed as follows in plain English: 


Retrieve supplier names for suppliers such that there does 
exist a shipment relating them to part 'P2'. 


b. The Negation of the Nested Query 
In addition, the contradiction of the above men- 
tioned GLAD query can easily be obtained by utilizing '.NOT 


EXISTS' as an operation on the '*!' sub-object. 
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SUPPL LER SOU ETRY 


SUEPELERS 













SUPP_NO# [GLAD QUERY] 


[WINDOW 1] 
STATUS 
Crny 
SNAME 
[SQL QUERY] 


> shuBeT SNAME 
> FROM SUPPER 


EXISTS 





[GLAD QUERY2] 
( SELECT * < 


SHIPMENT 






SHIP_NO# = SoUPPURER SUPE ae 












PART _NO# =e) 


QUANTITY [WINDOW 2 


Figure 21. Query Illustrating Nested Selects 


¢. The Use cfs! “for Teanslatuen 


Finally, it must be mentioned that the 









[GLAD QUERY ] 


] 


Vea 


an OM SHIPMENT 


>WHERE SHIP NO# = 
SUPPLIER.SUPP_NO# 


>AND PART NO# = 


sub- 


object is displayed for every object. It is not a real sub- 


object that would be contained as a database object. 


1%? 


The 


is a special designator or pseudo object that is used 
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for the sole purpose of translating a GLAD query to a nested 
select SQL query or retrieval of all sub-objects of a 
database cbisct. 


18. Retrieval With Aggregate Operations 


Aggregate operations can be utilized with '.P! 
operations on sub-objects or independently on the entire 
object to retrieve a numerical answer that is not directly 
stored in the database. The query utilizes the aggregate 
operation to calculate the retrieved result. For example, 
consider the below listed queries: 

1. Get the total number of suppliers supplying parts. 
2. Get the number of shipments for part 'P2'. 
3. Get the total quantity of part 'P2' supplied. 

All of these queries use aggregate operations to 
calculate the retrieved results of the query. 

a. GLAD QUERY--Total Number of Suppliers 

Figure 22 contains a GLAD query that utilizes 
two aggregate operations to retrieve the number of suppliers 
[aac are currently supplying parts. 

b. Retrieve the Number of Shipments for 'P2' 

Aggregate Operations provide the power and 
flexibility to the user to obtain computed results that are 
not directly stored in the data base. A COUNT operation 
performed on the '*' in the query window will allow the user 
to formulate an efficient query to retrieve the total number 


of tuples that meet a designated condition. 
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[GLAD QUERY ] 







SHIPMENT SOUR 


SHIPMENT 








SHIP_NO# COUNT DISTINCT 
PART _NO# 
QUANTITY 


SELECT COUNT (DISTINCT SHIP NO? )- 





2 scout SHE EMENTS 


Figure 22. GLAD Query with Distinct Count 


Consider a GLAD query that utilizes a simple 
aggregate operation to calculate the number of shipments for 
part 'P2'. The query is listed in Figure 23. 

This query will” simply count up alle. 
shipments in the database that has 'P2' for a shipment 
number in the database. 

ec. The Total Quantity of e)P2™ Supplied 

Aggregate operations can be used in conjunction 
with '.P' operations on designated sub-objects to compute 
specific computed values of these sub-objects. Consider the 
query in Figure 24 that utilizes the SUM function to 
Calculate the total quantity ot the “part “'E2"9 thaw 


supplied. 
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[GLAD QUERY] 


| SHIPMENT QUERY 


SHIPMENT | [SQL QUERY] 











> SELECT COUNT(*) 


SHIP_NO# 






| FROM SHIPMENT 


ease PART _NO# = 


PART _NO# 
oe 






QUANTITY 


Figure 23. Using COUNT on Object Name 


[GLAD QUERY} 


SHIPMENT [SQL QUERY] 
SUM (QUANTITY) 
SHIP_NO# SHIPMENT 


PART _NO# = PART NO# = 
Yee 


QUANTITY 





Figure 24. GLAD Query that Computes SUM of QUANTITY 


In a similar manner, queries can be formulated 


with the following aggregate operations: 


OF 


1. MAX will calculate the largest value of a sub-object. 
2. MIN will calculate the smallest value of a sub-object. 
3. AVG will calculate the average value of a sub-object. 
19. GROUP BY to Conceptually Rearrange the Data 
GLAD shall employ the GROUP operator to conceptually 
rearrange the translated table and retrieve partitions so 
that within one group all rows have the same value for the 
GROUP field. 
Consider the following query: 
For each part supplied, get the part number and the 
total quantity supplied of that part, excluding ship- 
ments from supplier 'D1'. 
A GLAD query shall make use of the GROUP function to 


accomplish the query. Consider the following GLAD query and 


the corresponding SQL query translation in Figure 25. 


B. GLAD QUERY OBJECTS THAT REFER TO OTHER QUERY OBJECTS 

The previously discussed queries showed GLAD objects 
composed entirely of simple sub-objects that hold atomic 
data. As mentioned earlier, one of the most powerful 
features of GLAD is the ability to represent complex non- 
atomic data as simple atomic data. However, queries must be 
translated in a two phase process to accomplish this type of 
representation. First, the query must be translated to 
extended SQL syntax. Second, non-atomic data types must be 
translated to primitive SQL syntax for the final SQL query. 


Figure 26 illustrates the results of this process. 
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[GLAD QUERY] 






SHIP_NO# 


PART _NO# 








QUANTITY 


[SOL QUERY ] 






Zao Gh ou Ol rye PART NO =< 





> FROM SHelPMeNyT 
WHERE SHIP NO# <> *SI’ < 


> GROUP BY PART _NO#; 


Figure 25. GLAD Query Using GROUP BY 


The query in Figure 26 shows what happens when a query 
has a sub-object that refers to another object. In this 
case, the sub-object CITY is a non-atomic sub-object of type 
TOWN. The TOWN object consists of NAME, LOCATED and 
POPULATION. The TOWN sub-objects are atomic sub-objects of 
type integer and character. 


1. Retrieval of a Non-Atomic Object 


The query requires the retrieval of the 
SUPPLIER.CITY sub-object. Since CITY refers to another 


object, TOWN, all the attribute values of instances of TOWN 
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SUPPLIBRSSOULR SHIPMENT QUERY 


SHIPMENT 


* 





SUPPIIERS 





* 











SUPP_NO# SHIP _NO# = hope 
STATUS PART NO# = 85 
Cry QUANTITY 

SNAME 








Soe Ol oer r ale Cri 


an 


> FROMM SUPP iOLeh eon EME 


WHERE SHTERNe7 = 1011 


AND PART NO# = 'P5';< 
IDTOWN < 
TOWN <— 
i eee ee 


-> SELECT TOWN.NAME, LOCATED, POPULATION 
FROM SUPPLIER, SHIPMENT, “IDTOWN, TO 


10 


> WHERE SHIP_NO# 
> AND PART NO# = 'P5'; 


Figure 26. Query with Objects that Refers to an Object 


that satisfy the query must be retrieved. Therefore, €piy 
is retrieved by translating the CITY sub-object to a TID 
(TOWN Identifer) attribute. | TID is used to join the 
SUPPLIER and TOWN tables. SUPPLIER is joined to the IDTOWN 


table. The object TOWN, which is referred to by the CITY 
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sub-object, is translated to the TOWN table and joined to 
the IDTOWN table. Ultimately, to retrieve the CITY sub- 
object that meets the query conditions, SUPPLIER must ke 
joined to both the IDTOWN table and TOWN table. All of the 
attributes in the TOWN table shall be listed in the SELECT 
line. In other words, every tuple that satisfies the query 
conditions will be selected. 
2. Use of Complex Objects to Specify Query Conditions 
Consider the query previously presented in Figure l. 
The query translation will change significantly ihe Ory aso ra. 
complex sub-object. Consider Figure 27 with CITY as non- 
atomic data of type TOWN. Relational operators can be used 
on CITY to specify query conditions by using an identifer 


table that refers to the TOWN table with the complex CITY 


object. 

In Figure 27, a query with the string value 'Paris' 
is used to specify a condition for the retrieval. However, 
CITY is of type TOWN and not type string. To avoid 


generating an error resulting from SQL's inability to 


utilize complex data, the line CITY = 'Paris' is translated 
to TIDNAME = 'Paris', and the SUPPLIER table is joined to an 
identifer table. The identifer table (IDTOWN) maintains 


string information that is not stored directly in the 
SUPPLIER table. The SUPPLIER and IDTOWN are actually joined 


on an integer value that is stored as an identifer in these 


a 


[GLAD QUERY ] 









SUPPLIER QUERY 


SUPPLIER 
[SQL QUERY] 


SUPP NO#, STATUS 










SUPP_NO# 
SUPPLIER 










STATUS 
> WHERE CITY = ‘Parisi 










Civy 


SNAME 






IDTOWN 


TIDNAME 


SELECT SSUPPING: jot] Uses 
EROM SUPPLIER el! TOWNS < 


WHERE TIDNAMES — Paris. 37- 


Figure 27. Non-Atomic Sub-Object with a Condition 


tables. This integer, referred to as TID, is used as a 
surrogate value to join these tables. Since the complex 
sub-object is not designated for retrieval, it will not have 
to be joined with the TOWN table. Most conditions that 
utilize relational operators on complex sub-objects will be 


performed on the information that is held in the identifier 


table. For example, CITY = 'Paris' will be translated into 
TIDNAME = 'Paris'. The operation is actually performed on 
the string value 'Paris'. Therefore, unless a retrieval is 
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specified on the complex sub-object, it will be unnecessary 


to join all three tables like the query in Figure 26. 


eee GLAD'S CORRESPONDENCE TO SOL 

The GLAD queries attempt to eliminate much of the 
difficulty associated with SQL queries. The GLAD queries 
remove much of the formulation of the relational syntax 
associated with SELECT, FROM, WHERE, AND and GROUP BY. 
Multiple objects can be used in a query by opening a query 
window for each object. These query windows will be trans- 
lated to either a SQL join or nested select query. 

Because GLAD will be built on an underlying relational 
model, the GLAD query windows have been developed by working 
backward from DB2 SQL to GLAD windows to ensure the best 
possible correlation. Therefore, the object oriented GLAD 
interface corresponds well to the SQL query language of an 
underlying relational system. In most cases, the GLAD query 
elements form a perfect one-to-one mapping to the relational 
backend. Therefore, at a higher, conceptual level, GLAD 
queries have the potential for effective and efficient 
transfer and translation to the relational system. 
Translating the data structures of the object oriented 
interface to a relational format requires easily accessible 


data structures and effective translation algorithms. 
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V. SYNTAX FOR THE GLAD SCHEMA 


In the previous chapter, the graphical query windows to 
formulate a GLAD database query were discussed at the 
database user level. In this chapter, the higher level 
schema for defining objects that will support the window 
interfaces of the previous chapter shall be discussed in 
detail. The schema presented for GLAD in Wu [Ref. 16:pp. 1- 
10} shall be examined in detail and used with the University 
Database example presented in Wu [Ref. l:pp. 1-10] to 
illustrate the schema definition of a GLAD database. Figure 
28 contains the syntax for the schema, defined in Wu [Ref. 
12D. 31, for GLAD. 

Each of the database items of Figure 28 shall be used to 
examine the schema for the database objects of the pedagogi- 
cal UNIVERSITY database. The user interface shall provide a 


view of the database as graphics objects. 


A. A VIEW OF THE UNIVERSITY DATABASE 

Consider the high level view of the UNIVERSITY database 
that will be presented to the user from Wu [Ref. l:pp. 1- 
LOW. The UNIVERSITY database's major database objects are 
shown in Figure 29. 

The schema definition for each of the above specific 


database objects shall be analyzed in detail. 
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Syntax For Schema Definition 
<db-schema> ::= <object-declaration> <object-declaration> 


eebyect-declaration> ::= + 
DEFOBJ <object-name> <attribute-declaration> ENDOBJ 


<attribute-declaration> ::= <attribute-name> : <type>; 

* 
<type> ::= <member-type> <or-list> | SETOF <member-type> 
<member-type> ::= <system-object> | <object-name> 
<or-list> ::= OR <member-type> | OR SETOF <member-type> 
<system-object> ::= STRING [ <size> ] | NUMBER 
mevze> 7::= | | 2[{3 | ..- | Maxint /* whole number */ 
<object-name> ::= /* string, uppercase */ 
<attribute-name> ::= /* string, uppercase */ 


Figure 28. GLAD Schema 


SLUDENT ! COMMITTEE 





EMPLOYEE 





Figure 29. User View of University DB 
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1. The STUDENT Object Schema 

The schema for the STUDENT object shall follow the 
GLAD schema definition convention. For the sake of clarity 
and space, the database definitions will be shown in a 
vertical manner. The STUDENT object is a complex database 
object that has both atomic and non-atomic attributes as 
sub-objects. The GLAD representation of the complex attri- 
bute MAJOR allows all of the attributes to be uniformly 
defined by the GLAD schema definition. Figure 30 represents 
the schema for the STUDENT OBJECT in GLAD, extended SQL and 


SOL syntax. 


GENERAL OBJECT DEFINITION 
<object-declaration> ::= DEFOBJ <object-name> 
<attribute-declaration>?* 
ENDOBJ 


SPECIFIC SPUDEN TI DERE FON 
7:—= DEFOR STUDENT 
NAME: string; 
AGE: integer; 
GPA: integer; 
MAJOR: DEPT; 
ENDOBJ 


Student 


GENERALIZED ESOL & SOL DEFINITION 


<table> ::= <table-name> <attribute-declaration>?t 


SPECIFIC BSOL STUDENT DERIND ETON 
STUDENTTABLE ::= STUDENT (NAME:string, AGE:integer, 
GPA: integer, MAJOR:DEPT) 


SPECIFIC S50 STUDENT DEP IN rion 


STUDENTTABLE ::= STUDENT (NAME:string, AGE:integer, 
GPA: integer, DID:integer, SID:integer) & 
IDDEPTTABLE ::= IDDEPT (DID:integer, DIDNAME:string) 


Figure 30. The STUDENT Object Schema 


76 


The schema for the STUDENT object is both easy to 
construct and effectively corresponds to the extended 
relational type schema. This extended SQL type schema is 
Similar to the schema that was defined for the GEM extension 
of a relational model in Tsur [Ref. 12:pp. 1 - 8]. Since 
the extended SQL STUDENT table contains complex data types 
it is unsuitable for use as a relational query. It must be 
joined with an identifier table that holds a string of 
characters. The character string is equivalent to the name 
of the complex data type. 

An effective correspondence between schemas shall 
prove to be fruitful for minimizing the translation scheme. 
However, we shall defer the discussion of the translation 
scheme and algorithms to accomplish the translation to the 
subsequent chapters. 

Of particular importance is the treatment of the 
MAJOR attribute in the STUDENT sub-schema. The higher level 
representation of the MAJOR sub-object, which is not atomic 
but is represented to the user like any other atomic type, 
is one of the most important features of GLAD. This feature 
ultimately allows the user to view everything in the 
database as real world entities that correspond to database 
objects. The disadvantage is design difficulties and 
challenges associated with the implementation and transla- 


Gron of this data to primitive SQL. 
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The ESQL to GLAD translator can substitute an atomic 
ESQL attribute directly for a corresponding SQL attribute in 
the translated SQL query. For the non-atomic attributes, 
this process requires a complicated translation vice an easy 
substitution for atomic attributes. The translator must 
analyze every line of the extended query and determine if 
any attributes in the line are not atomic. The translator 
will consult a table that contains all non-atomic attri- 
butes. If an attribute is non-atomic, the translator will 
call procedures that will form joins on surrogate identifier 
tables to express the complex data in primitive SQL con- 


structs. 


2. The DEPT Object Schema 


The DEPT object is related to every object in the 
UNIVERSITY database. The Schema for DEPT, shown in Figure 
31, contains both complex and atomic data attributes. 

The CHAIR object is a complex object of type 
FACULTY. The FACULTY object is a specialized instance of 
the EMPLOYEE object. NAME is a simple string type that 
contains the name of the university department. TENURED is 
a complex type of sub-object of type TPROF, and TPROF is a 
type of set that contains all the tenured PROFS in the 
UNIVERSITY database. Therefore, identifier tables will be 
needed for the TENURED and CHAIR sub-objects to formulate 
the primitive SQL query. In conclusion, the DEPT type of 


object is the center piece of the UNIVERSITY database. 
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GENERALZOBJECT DEFINITION 
<object-declaration> ::= DEFOBJ <object-name> 
<attribute-declaration>t 
ENDOBJ 


SEEeiri CODER DEE INET ION 
Dept ::= DEFOBJ DEPT 
CHAIR: FACULTY ; 
NAME. ‘string; 
DENURED: TPROF; 
ENDOBJ 


GENERALIZED ESOL & SOL DEFINITION 


<table> ::= <table-name> <attribute-declaration>t 


5S PECIPICVESOm DEPT DEFINITION 
DEPTTABLE ::= DEPT (CHAIR: FACULTY, NAME: string, 


TENURED: TPROF) 


SPECIE RC SObeDEPT DER INITION 


DEPTTABLE ::= DEPT (FID:integer, NAME:string, 
TID:integer, DID:integer) & 

IDFACULTYTABLE ::= IDFACULTY (FID:integer, 
FIDNAME:string) & 

IDTPROFTABLE ::= IDTPROF (TID:integer, 


TIDNAME: string) 


Figure 31. The DEPT Object Schema 


Every object of the database is related to the DEPT object. 
GLAD interfaces have the unique capability of treating 
complex data types like atomic data types. This unique GLAD 
capability will be used to provide the user the best 
possible data definition, data access and data manipulation 
capabilities. 
a The EMPLOYEE Object Schema 
The EMPLOYEE Object is a generalized object that 


includes FACULTY and SECRETARY specialized objects. The 


Pec! 


Schema for the generalized EMPLOYEE object is shown in 


Figure 32. 


GENERAL OBJECT DEFINITION 
<object-declaration> ::= DEFCBJ <object-name> 
<attribute-declaration>* 
ENDOBJ 


SPECIPICABRME ROY E Rape iii iol 
Employee ::= DEFOBJ EMPLOYEE 
NAME: string; 
PAY; real; 
DEPARTMENT: DEPT; 
JOBTYPE; CATEGORY; 
ENDOBJ 


GENERALIZED ESOL & SOL DEFINITION 
<table> ::= <table-name> <attribute-declaration>? 


SPECTEPIEC ESOL, EMPROYEESDERINITION 
EMPLOYEETABLE ::= EMPLOYEE (NAME:string, PAY:real, 


JOBTYPE: CATEGORY, DEPARTMENT: DEPT) 


SPECT RIC SOL TEMELOVER DEFINETION 


EMPLOYEETABLE ::= EMPLOYEE (NAME:string, PAY:real, 
CTID: integer, DID:integer, EID:integer) & 
IDCATEGORYTABLE ::= IDCATEGORY (CTID:integer, 
CTIDNAME:string) & 
IDDEPTTABLE ::= IDDEPT (DID:integer, 


DIDNAME: string) 


Figure 32. The EMPLOYEE Object Schema 


The EMPLOYEE object contains both complex and atomic 
data objects. NAME is the name of the specific EMPLOYEE. 
The PAY attribute is of type real to allow the decimal 
representation of the EMPLOYEE salary. DEPARTMENT is of 
type DEPT and is analogous to the MAJOR attribute of the 
STUDENT object. However, the user is presented with 


distinct conceptual representations of both of these 
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attributes. The system must translate distinct sub-objects 
of the same complex type and correlate these sub-objects to 
relational attributes for translation. At the schema level, 
the translation process is accomplished with identifier 
tables for complex objects. 
4, The COMMITTEE Object Schema 

The COMMITTEE Object is a complex object that has 
both atomic and complex data objects. In addition, COMMIT- 
TEE is associated to the EMPLOYEE object through the MEMBERS 
sub-object. Figure 33 shows the entire COMMITTEE schema and 


the COMMITTEE to EMPLOYEE association. 


GENERAL COMMITTEE DEFINITION 
<object-declaration> ::= DEFOBJ <object-name> 
<attribute-declaration>* 
ENDOBJ 


aero Lr he COMM mn LEE. Oba hear 
Committee ::= DEFOBJ COMMITTEE 
NAME: string; 
MEMBERS: FACULTY; 
PURPOSE: string; 
ENDOBJ 


GENERALIZED ESOL & SOL DEFINITION 
<table> ::= <table-name> <attribute-declaration>* 


SeECiric Eo@in COMMELTEER. DEE INITION 
COMMITTEETABLE ::= COMMITTEE (NAME:string, 


MEMBERS: FACULTY, PURPOSE:string) ; 


SPECIELC SOLSCOMMELRTER DEFINITION 


COMMITTEETABLE ::= COMMITTEE (NAME:string, 
FID: integer, PURPOSE:string) & 
IDFACULTYTABLE ::= IDFACULTY (FID:integer, 


FIDNAME:string, CMID:string) 


Figure 33. The COMMITTEE Object Schema 
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B. SCHEMA CONSIDERATIONS 

An easily understandable and usable schema is important 
for both the designer and user of the database. The 
previous discussion illustrated the syntax for schema 
definition cf the GLAD UNIVERSITY database. This higher 
level approach to database is well suited to naive or 
inexperienced users. The burden of implementing the complex 
sub-object types is placed entirely on the implementors of 
GLAD. The higher level object oriented approach to implemen- 
ting the schema may be well suited for the user but presents 
unique challenges to the designer. 

Unique design challenges await the database designer. 
The GLAD schema must be implemented at the physical level 
with effective data structures that will adequately support 


the user interfaces. 
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Vit oS tis Pave lUuRES 10 SUPPORT THE INTERFACES 


Efficient and effective data structures must _ be 
developed and employed for supporting the window interfaces 
to the GLAD user. GLAD's data structures maintain the 
information that is supplied to the GLAD window interfaces 
and displayed to the user. Object oriented data structures 
are particularly well suited for the task of supporting the 
GLAD windows. ACTOR has many classes that can be utilized 
to construct efficient and easily accessible data struc- 
tures. Of these classes, various descendants of the 


Collection class are ideal for holding database object 


information. The Collection class is easily accessible 
through keys, indexes and elements. In addition, a Collec- 
tion can store heterogenous information. Moreover, various 


complex and primitive data items can be stored in the same 
Collection. A GLAD database object is a Collection of GLAD 
objects. To access different databases, a global variable 
Collection named GLAD must be created. This Collection will 
hold all of the GLAD databases. In other words, we can view 
GLAD databases in the following manner: 


1. Databases contained within the GLAD application 
are ultimately Collections of Collections. 


2. Each database Collection consists of a group of 
database objects. 


83 


3. Each database object is a Collection of sub- 
objects that are analgous to tables and 
attributes of the relational model. 

A. A USEFUL ANALOGY 

An analogy that compares a GLAD database to an oifice 
building will be useful for illustrating the capabilites of 
the Collection class in developing GLAD data structures. An 
office building with many floors can be compared to a 
Collection with many elements. The Collection corresponds 
to. the building, and the elements of the Collection corres- 
pond to the floors that are contained within the building. 

The elements of the collection are database objects that 
define a database. Each of these objects are either related 
to, associated with or used in conjunction with other 
objects that define aggregate or generalized objects. The 
floors of the building correspond to the elements of the 
collection: Each element carries out tasks that are inte- 
grated to accomplish a function or represent specialized 
functions of a generalized office function. The objects of 
the database are collections of sub-objects. Each of these 
sub-objects describes the parent object. The parent object 
is composed of one or more sub-objects. 

Rooms that are located on the floors correspond to the 
sub-objects of the database. These rooms carry out activi- 
ties that contribute to tasks that are assigned to each 
Loar: In other words, these room activites describe the 


floor's tasks. 
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Additional databases can be added to GLAD by increasing 
the size of the Collection. Collection size can be increas- 
ed through the grow method. Similarly, if we need more 
floors for the building, additional floors can be added onto 


the top of the building. 


eee ABOUT COLLECTIONS 
The ACTOR manual states that the class Collection is the 
richest part of the ACTOR class tree. Collection is defined 


as an object that holds a group of sub-objects called 


elements. However, the Collection class can not be directly 
accessed. It is a formal class that provides universal 
properties for descendents. The Collection descendents 


serve as types of Collections that hold database objects. 
Array, Set and Dictionary are descendents that can be used 
to hold GLAD objects. [Ref. 4:pp. 169-210} 
1. Arrays For Glad Objects 

An array is a descendant of the formal class 
IndexedCollection. The IndexedCollection is a type of 
collection in which individual elements are referenced by 
integer values Whitewater (Ref. 4:p. 164]. In addition, the 
IndexedCollection unifies the Array, ByteCollection and 
Interval classes. ByteCollection, Array and Interval can be 
classified as siblings in the ACTOR class tree. 

An Array can be created to hold database informa- 
tion. The Array information can be accessed by refering to 


the Array name with the bracketed index of the desired 
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element. The Array class shall be utilized to maintain at- 
tributes\sub-objects of a particular database object. The 
attribute array will be one of the elements of the database 
object collection. 
2. The Dictionary Class 
The Dictionary is a type of KeyedCollection class. 
The keyed collection allows direct access to elements 
through use of a user specified index/key. The KeyedCollec- 
tion maintains elements in an unordered manner analogous to 
set elements. The advantages of the KeyedCollection over an 
ACTOR set are substantial. An ACTOR set has elements that 
can only be accessed through membership operations. The 
element itself must be specified to be retrieved from the 
SEL. A KeyedcCollection element can be accessed through a 
user specified index/key. In many cases, the user may have 
access to the key/index but not know the name of the 
element. The KeyedCollection has greater flexibility than 
the Set and powerful operations that the Set does not 
possess. The below listed operations can be performed on 
Dictionaries that are descendants of KeyedCollections. 
a. The Add Method 
An element can be added to a Dictionary with the 
inherited KeyedCollection method Add. An Add message to the 
method takes two parameters and can be utilized in the 


following manner: 
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Pe Dacacdickionaryea= new(Dictionary, 10); <CR> 


Peeeadd(Datadictionary, "Student", “University Object 1"); 
<CR> 
cee watadictionary; <CR> 


Pee Datadictinary ("Student"). 
b. The At Method 

The At method can be used to obtain a value that 
is associated with a specified user defined key. The At 
method can be used in the following manner: 

ieee at(Datadictionary, “"Student"); <CR> 
eee University Object 1". 

"University Object 1" is the returned item that 
is stored at the above specifed user defined key. If an 
attempt is made to access an item that either does not exist 
or has a non-existent key, nil is returned by the system. 

c. The Remove method 

The Remove method can be used to remove an item 
from the Dictionary. The Remove method deletes the desig- 
nated element and returns the key, but if it does not find 
the designated element, it returns nil. Consider the 
following example: 

1. remove(Datadictionary,"Student") ; <CR> 
fee  oeudent". 
d. Other Useful Methods 


The Dictionary class possesses other methods 
that can be used to return association objects, enumerate 


elements in the Dictionary, get the key and values of 


S7 


elements, and a host of other very useful and powerful 
operations. 
e. GLAD Object Use of the Dictionary Class 

The Dictionary will be utilized to hold the 
major objects of the database. Powerful methods of manip- 
ulation and access will be made available to the data user 
from the Dictionary Class. In addition, the database can 
easily be expanded through the grow method. Old objects can 
be purged and space obtained through the reclaim method. 

The Dictionary class seems to be well suited for 
database objects. When information is desired about a 
particular object, it should be a simple matter to access 
the information through user defined keys. The access 
method is analogous to looking up information in a diction- 
ary with the alphabetized word index. 

The above-mentioned methods will be transparent 
to the user. The methods shall be utilized to support the 
window interfaces and help provide the best possible data 
manipulation environment. Ultimately, a Dictionary holding 
a GLAD database, such as the University database discussed 
in Wu [Ref. l:pp. 1-10], will be created. The dictionary 
would contain all the major database object and would be 
represented by the system in the following manner: 


Univdb (#Student, #Employee, #Dept, #Committee) 
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3h c The Set Class 


An ACTOR set is a collection of unique elements. 


@oly unique elsrents can Selong to a Ser. eet (eahmenoe 
contain duplicate elements, and any attempt to add an 
element that is already ccntained in the Set will fail. An 


ellement is either a member of the Set orenot a member of the 
Set. Set membership operations are the only operations that 


are allowed to be perfcrmed on an ACTOR Set. An ACTOR Set 


can store 16K-1 elements. The cardinality of a set is 
maintained in the tally instance variable. [Ref. 4:p. 201] 
a. Set Operations 


From the Collection class, the set inherits both 
add and remove methods to put elements into and remove them 
from the Set. 

b. GLAD Object Use of Sets 

The Collection that maintains all of the GLAD 
databases shall be a set. Essentially, these databases 
merely have to be added to or removed from the GLAD applica- 
eon Any data manipulation and data definition would be 
done on the specific databases. The Set class is limited in 
capability but is adequate to maintain the various GLAD 


databases. 


Cx GLAD DATA STRUCTURES FOR THE UNIVERSITY DATABASE 
To illustrate the use of the GLAD data structures, the 
University Database of Wu [Ref. l:pp. 1-10} shall be 


utilized to analyze database objects as instances of GLAD 
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data objects. We shall define instances of GLAD objects for 
the higher-level STUDENT, COMMITTEE, EMPLOYEE and DEPT 
objects. 
1. The DEPT Object 

The DEPT object is a very important object of the 
UNIVERSITY Database. DEPT is related to all of the other 
major objects in the UNIVERSITY database. The DEPT object 
contains both atomic and non-atomic sub-object or attribute 
types. The attributes are CHAIR, shorthand for chairman, of 
type FACULTY; NAME, the DEPT objects only atomic attribute, 
of type string; and tenured, a complex set type attribute, 
of type TPROF. All of the other UNIVERSITY database objects 
contain a sub-object of type DEPT. In summary, DEPT 
connects the objects of the database. 

a. DEPT as an Instance of GLAD Object 

Consider a Dictionary named DEPT with keys of 
"name," "location," "members," "type" and "attributes." The 
keys will be utilized to access the following information: 
1. "name"--The string name of the object "DEPT." 


2. "“location"--A point which holds the origin of 
the rectangle. For example, 30@30. 


3. "members"--of type Deptfile that contains tuples 
of the DEPT object. 


4. "type"--of type char. Hither “a"@ereg" Lor agg— 
regate or generalized. DEPT is "a" since it is 
the aggregation of several sub-objects. 


5. “attributes"--an array of attributes. Each array 


element shall contain an ordered pair of the 
data attribute name and object name. [Ref. 16:p. 6] 
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b. Files and Delimiters for DeptFile 
In addition to the above information, the follow- 
ing points need to be emphasized. First, the "members" 
element index of the Dictionary refers to a DeptFile of type 
TextFile. The entries in the file will be represented in 
the following manner: 


Lum@"Computer Science"@Set("Lum" "Hsiao" "Wu" "McGhee") | 
Latta@"Math"@Set("Lucas" "Weir" "Latta" "Devito") | 


The "@" and "|" symbols are used respectively to delineate 
fields and tuples. The final element of the tuple consists 
of a set of tenured professors for each department. The 
elements of this set are strings of names. The first 
element in the tuple is the name of the department chairman 
and is of type faculty. The name will probably be contained 
within the set of tenured professors. The name attribute is 
a string value. This string is not the same type as an 
element in the set of tenured professors, TPROF. 
2. The STUDENT Object 

The STUDENT object is an aggregate object composed 
of both atomic and complex sub-objects. NAME is an atomic 
attribute of type string, AGE and GPA are atomic sub-objects 
of type integer, and MAJOR is a complex sub-object of type 
DEPT. These previously mentioned objects define the aggre- 
gate STUDENT object. In essence, the complex aggregate 


object DEPT is nested within the STUDENT object. 
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a. STUDENT as an Instance of GLAD object 

An instance of the STUDENT object is similar to 
the instance of the DEPT object. The major difference is 
that STUDENT maintains DEPT as one of its attributes or sub- 
objects. In other words, the STUDENT object is an instance 
of a complex GLAD object. STUDENT maintains another 
instance of a primary database object, MAJOR of type DEPT, 
as an attribute. The attribute array maintains the attri- 
bute names and shall be represented in the following manner: 

- STUDENT("attributes") = 
Array( Array("NAME" #basic) Array("AGE" #basic) 
Array("GPA" #basic) Array("DEPARTMENT" #DEPT) ; 

As stated in Wu [Ref. 16:pp. 1-7], basic is used 
when the attribute type is defined in ACTOR. The Object 
name is necessary for appropriate shading to deserine the 
window interface. If the object name is not defined in 
ACTOR, the name of the object will be a complex type, such 
as DEPT or TPROF, that has been defined for the database. 

3. The EMPLOYEE Object 

The EMPLOYEE Object, of the University database, is 
a different kind of object than the DEPT and STUDENT objects 
that have been discussed. EMPLOYEE is a type of generalized 
object. This type of object is a generalized type of a more 
specialized object. FACULTY and SECRETARY are specialized 
objects of the more generalized EMPLOYEE type. The attri- 
bute "JOBTYPE" of type CATEGORY indicates the type of the 


specialized EMPLOYEE. 
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4. The COMMITTEE Object 


The COMMITTEE Object is an aggregate object. It has 
attributes of "NAME", "MEMBERS" and "PURPOSE." The "MEMBERS" 
attribute is of type FACULTY. FACULTY is a complex special- 
ized object that is nested within COMMITTEE. This implicit 
relationship forms an abstract, higher level association. 
Specifically, COMMITTEE is associated to EMPLOYEE through 
the specialized FACULTY object. 

5. The Higher Level Abstractions 
The above objects illustrate how the higher level 


abstractions of generalization, aggregation and association 


are supported by GLAD. In addition, GLAD also supports 
classification of objects. Every specific element of an 
object can be classified as that type of object. bor 


example "John Smith" is an element of "MEMBERS" of type 
StudentFile. Therefore, "John Smith" is classified as a 


STUDENT. 


D. THE QUERY COLLECTION 

The data structures that collect information from the 
query window shall be designated as query collections. 
Essentially, these data structures shall take information 
from the database user via the query window and pass it toa 
translator. An array shall be utilized to obtain the query 


mafLormation. 
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1. Query Array Entries 

The array entries shall contain all of the data that 
is pertinent to the designated query. Each entry shall 
consist of an ordered pair of items. The first entry shall 
contain the object name and any instructions to be performed 
on the query object. Subsequent entries will contain the 
attribute names and any instructions to be performed on the 
attributes. The following is the general form for a 
possible representation of the GLAD query collection: 

- QUERYCOLLECTION ("OBJECTNAME") = 


Array( Array(OBJNAME OBJINST) Array(AttNamel Inst1) 
Array (AttName2 Inst2) Array(Attrname3 Inst3); 


2. An Example Query Collection 
The general form contains all of the pertinent 
information of the query collection in object oriented 
format. A specific example shall further illustrate the 
query collection. Consider a query of the STUDENT object of 
the UNIVERSITY database where the goal is to retrieve the 
names of students ane have grade point averages equal to or 
higher than 3.5. After the user inputs information into the 
STUDENT query window, the query is represented by the query 
collection in the following manner: 
- QUERYCOLLECTION(#STUDENT) = 
Array( Array( #STUDENT " Array (at sa" a) 
Array( #SNAME ".P" ) Array( #AGE " " 
Array( #GPA ">= 3.5") Array( #MAJOR " do) ie 
The above returned example Array could be obtained 


at the ACTOR level if 'QUERYCOLLECTION(#STUDENT) ; <CR>' was 


typed into the ACTOR display window. The system is asked to 
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show the representation of the STUDENT query array contained 
in the indexed collection that holds all query collections. 
The information is taken as symbols for the first element of 
each array and strings of characters for the second element 
instructions. A blank string is used to indicate no 
instructions on the object or attribute. The above example 
is pedagogical in nature, and it is not intended that the 
user would have access to the ACTOR system. The example 
merely shows the physical representation of the query 


object. 


E. THE PHYSICAL DESCRIPTION 

The data structures that support the GLAD interfaces 
have been discussed in great detail. The Array, Dictionary 
and Set classes, direct descendants of the Collection class, 
are ideally suited for supporting the GLAD interfaces. 
Essentially, the entire GLAD database application can be 
implemented as a Collection of Collections. The pedagogical 
University database example illustrated the use of specific 
ACTOR classes as data structures for supporting instances of 
GLAD objects. [Ref. l:pp. 1-10] 

Both physical and logical views of the GLAD data 
structures have been discussed. Data structures to support 
the window interfaces have been described in detail. 
Information contained in these data structures must be 
translated into extended SQL and ultimately primitive SQL to 


obtain data from the relational backend. Ultimately, data 
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from the supporting data structures must be accessed in 
object oriented format, translated to relational format, and 
retranslated to object oriented format. The translation 
scheme and algorithm for the interfaces will be discussed in 


the subsequent chapter. 
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VII. ALGORITHMS FOR THE TRANSLATION 


The window interfaces and data structures that will 
support GLAD have been discussed and analyzed in great 
detail in the previous chapters. Essentially, all of the 
objects and windows support the GLAD system with object 
oriented interfaces to the user and to the relational 
database system. GLAD can be thought of as a bridge that 
data travels on to the relational side and back to the 
object oriented side. However, this bridge is invisible to 
the user. From the user's vantage point, he only sees 


object oriented data. 


A. THE TRANSPARENT LINK TO THE SYSTEM 

Implementors of databases that use higher-level inter- 
faces spend a great deal of time and effort in designing the 
database system in a manner that will allow the user to be 
ignorant of the design and implementation details. There- 
fore, when the user formulates a query, he does not have to 
know how the system is actually retrieving the data. With 
GLAD, efficient implementation of the higher level abstrac- 
tions, supporting data structures and window interfaces is 
critical for obtaining an efficient database system with 
reasonable response time. Since the user is removed an 


additional level from the physical database, an efficient 
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implementation of the interface is extremely important for 


retrieving data in a reasonable amount of time. 


le GLAD ON TOP OF SOL 

As mentioned earlier, GLAD is to be built on top of a 
SQL based relational database system. It is anticipated 
that the SQL based system will function in the same manner 
as it would if it were the end user system with the SQL 
query language as the interface to the user. Instead of 
being directly supplied information by the user, the SQL 
based system will obtain information from GLAD and return 
data to GLAD in a manner that is entirely transparent to the 
user. 

Consider a modular view of GLAD sitting on top of a SQL 
based system, DB2 by Date [Ref. 14:p. 103], and main com- 
ponents. A diagram of the system is shown in Figure 33. 

A user of a SQL-based relational database system would 
perceive the database as base tables. In Date [{Ref. 6:p. 
103], the following definition of tables and views are 
given: 

A base table is a "real" table--i.e., a table that 
physically exists, in the sense that there exist 
physically stored records, and possibly physical 
indexes....By contrast, a view is a "virtual" table-- 
i.e., a table that does not directly exist in storage. 

With GLAD the user will be entirely shielded from the 
lower half of the diagram that uses SQL as the end user 


interface and tables and views to represent data entities. 


Instead of tuples in tables, the user perceives data as 
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Figure 34. GLAD and SQL System Modules 


graphics objects that maintain all the relevant facts and 
information about the data entities. Therefore, the user 
does not have to navigate through the rudimentary constructs 


of the relational SQL query language. 


C. THE TRANSLATION SCHEME 

A transparent link to the user can be formed with an 
effective translation scheme and efficient algorithms to the 
Support the scheme. Consider the translation scheme of GLAD 
in Wu (Ref. 16:p. 5]. It is shown in Figure 35. 

The left side of the diagram contains the data manipul- 
ation language scheme. The user formulates a database query 
with the query window. The data from the query is collected 


from the query window in an object query collection. Next, 
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Figure 35. Translation Scheme 


the query collection is translated into extended SQL syntax 
by the GLAD query translator. Then, the extended SQL query 
is finally translated into SQL syntax. The formatted SQL 


query is used by the relational database model to retrieve 
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or select information stored in the database. The relation- 
al query result is sent to a relational-to-GLAD object 
reformatter to change relational query results to object 
oriented format. The query results, now in GLAD object 
format, are sent to the GLAD query result displayer. The 
result displayer takes the query result information and 
displays the results to the user in a result window. 

The right side of the diagram contains the data defini- 
tion language scheme. The user defines his database through 
the create database window. Information from the create 
window is collected by a create data base object and sent to 
the GLAD database generator. Data Definition is completed 
and the data is put into extended SQL syntax. The ESQL-SQL 
translator translates the extended SQL query and formulates 
the syntax for the SQL create table operation. The tables 
are then created and stored in the database. This diagram 
presents a high level view and summary of GLAD used in 


conjunction with a relational data base model. 


D. AN ALGORITHM FOR THE TRANSLATION OF GLAD 

As mentioned earlier, GLAD objects move across a bridge 
like interface to the relational system. By the time these 
objects arrive at the relational system they must be trans- 
lated or converted to relational format. The relational 
system will only understand commands and queries in its 
native query language. Therefore, a generalized translation 


algorithm to accomplish conversion from object oriented 
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format to relational format must be developed and imple- 
mented. Consider the translation algorithm contained below 


in’ figure 36. 


if (MORE_THAN ONE OBJECT USED IN QUERY) then 
JOIN _OBJECTS; 


for i := 1 to NO PARTIAL QUERIES IN QUERY do begin 


if (INSTRUCTIONS ON OBJECT NAME(i)) then 
OBJ_OPERATIONS (i) ; 


while (EXECUTE_AND DECODE(i)) do 
begin 
if (ASTERISK FOR_ATTRIBUTE NAME(i)) and 
EXISTENTIAL — , QUANTIFIER(i) then 
SPECIAL OPS(i) 
else if (DOT_P_ON ATTRIBUTE(i)) then 
RETRIEVE SELECT (i) 
else if (NO_INSTRUCTIONS(i)) then NO _OP(i) 
else if (INSTRUCTIONS ON _ ATTRIBUTE (i) ) then 
RELATIONAL OPERATORS; 
end; 


if (not EXECUTE AND DECODE(i)) then 
RESET GLOBAL COUNTER; 


end; { for i := 1 to NO PARTIAL QUERIES IN QUERY } 


Figure 36. The GLAD Translation Algorithm 


The algorithm of Figure 36 shall be used to make the 
translation to extended-relational format by accomplishing 
the correlation of specific object oriented constructs to 
relational constructs, and substituting or converting these 


constructs to extended SQL format. 
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E. AN ANALYSIS OF THE TRANSLATION ALGORITHM 
The algorithm to translate the GLAD query divides the 
query collection into number of objects, object instruc- 
tions and attribute instructions to formulate the SQL query 
on a line by line basis. The SQL translation is handled in 
a line by line manner to form the SELECT, FROM and WHERE 
lines that define the major components of a SQL query. 
Consider the translation of any GLAD query that consists of 
a query collection that has sub-queries on objects. The 
following major query items must be translated: 
1. The number of objects in the query. 
2. Any instructions on the object name. 
3. Specific instructions for each attribute. 
1. If There are Multiple Query Objects 
If there are multiple objects used in the GLAD 
query, these objects must be joined as tables in the SQL 
query. Simple Objects can be directly correlated to a table 
that exists in the relational database. Complex Objects can 
be directly correlated to one primary table and one or many 
supporting identifier tables. It is anticipated that the 
create database function of GLAD will create primary rela- 
tional tables that have the same name as the corresponding 
database object. Therefore, the translation will be able to 
substitute the object names directly into the FROM line of 


the SQL query. This process will be accomplished by the 


Los 


implementation of the following portion of the translation 
algorithm: 


- if (MORE_THAN ONE OBJECT USED IN QUERY) then 
JOIN OBJECTS; 


In a conventional manner, :IORE THAN ONE OBJECTEWe r= 
_IN_ QUERY would be implemented as a function that returns a 
boolean value of true if multiple objects are used for the 
query. The query collection would be scanned by the 
function. If true was returned, a procedure called JOIN OB- 
JECTS would be utilized to formulate a relational join on 
the from line of the SQL query. 

2. Each Object as a Partial Query 

Each object that is used to formulate the GLAD query 
shall be considered to be a partial query for the GLAD 
query. Therefore, each of these objects must be decoded by 
the translator. The following portion of the algorithm 
steps through each of the objects in the algorithm: 

- for i := 1 to NO_ PARTIAL QUERIES IN QUERY do 
3. Decoding the Individual Objects 

Inside of each iterative step of the above loop, the 
instructions on the objects and attribute names are decoded. 

a. Decoding Object Instructions 

First, consider decoding instructions on the 

object name. Instructions on attribute names are used to 
print out string messages in the query. These messages make 


the returned results more understandable. The following 
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portion of the algorithm shall accomplish the translation 
of object instructions: 


- if (INSTRUCTIONS ON OBJECT NAME(i)) then 
OBJ OPERATIONS (i); 


If there are any instructions to be carried out 
on the object, such as a string to be returned with the 
retrieved values, they will be executed through a procedure 
named OBJ _OPERATIONS(i). This procedure will be called if 
a function called INSTRUCTIONS ON OBJECT _NAME(i) returns a 
boolean value of true. The function will evaluate to true 
if the attribute entry that holds object instructions does 
not contain a blank string. 

b. Decoding Attribute Instructions 

Each query collection has an array of ordered 
pairs that contain the attribute name and specific instruc- 
tions that are to be performed on that attribute. The 
following portion of the algorithm steps through each 
attribute in the array and decodes the attribute instruc- 
tions: 

- while (EXECUTE AND DECODE(i)) do 

This system shall continue to execute this 
portion of the algorithm until all of the attributes have 
been decoded. Essentially, EXECUTE_AND DECODE(i) is a 
function that returns a boolean value of true as long as 
attribute instructions remain to be decoded. The attri- 


bute's are referenced in specific decode procedures by a 


GS 


global counter that is reset when each sub-query is decod- 


ed. After an attribute's object oriented instructions are 
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decoded, contro@of the translation grecurns ce) 22s Goome 
the while loop. While decoding attribute instructions, the 
translator keys on the following items for the translation: 


1. An asterisk for the attribute mane used in 
conjunction with an existential quantifier 


2. A '.P' operation for an attribute instruc- 
tion to indicate an attribute retrieval 


3. A blank character string for attribute 
instructions 


4, Relational operators for attribute instruc- 
tions. 


(5) Asterisk and Existential Quantifier. 
Special operations will be executed if both functions 
evaluate true in the following portion of the translation 
algorithm: 
- if (ASTERISK FOR ATTRIBUTE NAME(i)) and 
EXISTENTIAL QUANTIFIER(i) then 
SPECIAL OPS (i) 

The SPECIAL OPS(i) procedure shall formu- 
late a nested select query from the pseudo attribute 
asterisk '*' containing instructions of '.EXIST'. However, 
if some type of instruction other than the existential 


quantifier is used with the '*' attribute, a nested select 


query will not be formed. 


(2) '.P' Operations for Retrieval. If the 
attribute instruction field contains a '.P', then that 


particular attribute will be designated for retrieval as 
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indicated by the below listed portion of the translation 
eaigorithm: 
=) af (DOT _P ON _ATTRIBUTE(i)) then RETRIEVE_SELECT(i) 

DOT P ON _ATTRIBUTE(i) is a boolean function that 
wide call the RETRIEVE.SELECT procedure if the function 
evaluates true. The function shall evaluate true when '.P'! 
is contained in the character string for attribute instruc- 
tions. In addition, it must be emphasized that '.P' can be 
qualified with further operations that the translator will 
handle. 

(3) No Instructions on the Attribute. If the 
instruction field contains a blank character string, then a 
simple no-operation procedure is executed and control is 
returned to the main decode loop after the attribute counter 
is incremented. The following portion of the algorithm will 
execute the no-operation procedure if the boolean function 
evaluates to true: 

- if (NO_INSTRUCTIONS ON ATTRIBUTE(i)) then NO_OP(1i) 

(4 Relational Operators { =, <>, <, > }. lise 
instructions exist on the attribute besides those that have 
already been covered, the instructions will be relational 
operators. If the attribute instruction field contains 
equal to (=), not equal or unequal (<>), less than (<) or 
greater than (>), the INSTRUCTIONS ON ATTRIBUTE(1i) function 
will evaluate to true. The RELATIONAL OPERATORS procedure 


“wll be invoked to handle the attribute instructions. 
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FEF. FROM EXTENDED SOL TO SOL SYNTAX 

As previously discussed, the correlations between the 
object oriented to extended SQL syntax are nearly a perfect 
one-to-one correspondence. However, the format of the 
extended SQL syntax is not suitable for the final SQL query. 
This extended syntax shall translate the complex data types 
of the extended query to atomic data types. Through the use 
of a join on a surrogate identifier table, the complex data 
type will be represented in the relational database as 
atomic data. Consider the following algorithm that is 
contained in Figure 37 and will be used by the ESQL to SQL 


translator. 


for i := 1 to NUM_LINES IN EXTENDED QUERY do begin 
if ESQL Line CONTAINS COMPLEX DATA(i) then 
begin 
TRANSLATE ATOMIC DATA CONSTRUCTS (i) ; 
COMPLEX := true; 
end; 
if COMPLEX then 
JOIN IDENTIFIER TABLES WITH OBJECT TABLE 
else 
SQL EQUALS ESQL 
end; 


Figure 37. Algorithmytor Fool sto.soL 
Essentially, the ESQL to SQL translator will be required 
to iterate through an array type structure that holds the 


complex data, parse the data, and substitute atomic con- 


structs (i.e., DID: integer ——— VWAtoR. Sear an Then the 
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surrogate identifier table will be substituted in the FROM 


imegem(1.e., FROM DEPT, IDDEPT <-- FROM DEPT ). 


G. A TRANSLATION EXAMPLE 

Consider a simple example to illustrate the entire 
translation process. The database user wishes to make a 
STUDENT query that will retrieve all student names for 
students that have a grade point average of greater than or 
equal to 3.5 and are math majors. The first step in the 
query process is putting this plain English query informa- 
tion into the query window. Figure 38 illustrates the 


STUDENT query window after the user has entered the data. 





| STUDENT QUERY 


| 
Pre Se tS~SY 
STUDENT | 


| 
| ‘ | 
| 


| SNAME | .P 

: AGE 

GPA | eS 

| MAJOR | = 'MATH' | 


Figure 38. GLAD Query Window 


After the user has entered the above information, a 
method that loads the query collection shall be utilized. 


The query collection shall contain only one element: 
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- QUERYCOLLECTION(#STUDENT) = 
rray( Array( #STUDENT " Me Rete a Uy 
Array( #SNAME ".P" ) Array( #AGE " Ue) 
Array( #GPA “>= 3.5") Array( ;MAJOR “MAUI: 
Next, the STUDENT element will be translated by the GLAD 
query translator into ESQL syntax. 
1. Number of Objects in the Query 
The first step in the translation is determining if 
there is more than one object used in the query. In the 
example, there is only one object in the query. The 
function MORE THAN ONE _OBJECT_USED_IN_QUERY evaluates to 
false, and the procedure JOIN OBJECTS is not called. 
Moreover, the ESQL FROM line will only have one table. At 
this point in the query the ESQL query array only has two 


elements that are not blank. Figure 39 contains the ESQL 


query after the FROM line has been translated. 


ESQL ARRAY 


ji | SELECT 
| 
2. FROM STUDENT | 


Sn OS 
| 3 | @@@GEEEEEE : 


4 | e@@eeeeeeee | 
| _—_ 
5 | eeeeeeeece | 





Figure 39. ESQL Array during Query Translation 
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At this point, the attributes have not been decoded 
so the only lines that are resident in the ESQL array are 
the SELECT and FROM STUDENT lines. The otner lines nave 
been initialized to '@@@@a@@@ee@ae@' which is a sentinel for 
decoding. 

2. Number of Partial Queries in Query 

Each of the objects in the query collection repre- 
sent a partial query. The loop with i := 1 to NO PAR- 
TIAL QUERIES IN QUERY will execute only once for the example 
query of Figure 38 because there is only one query object in 
the query collection. 

3. Decoding the Object and Attribute Instructions 

The loop while EXECUTE AND DECODE(i) will continue 
to execute until the function EXECUTE_AND DECODE(i) evalua- 
tes to false. 

a. Decoding the Object Instuctions 

The query collection is checked to determine if 
there are object instructions that must translated. The 
first element in the query array is evaluated by the 
function INSTRUCTIONS ON OBJECT NAME(i). The function will 
check to see if the instruction field has instructions. If 
the field is blank, the function will return a boolean value 
Seetrue and call OBJ OPERATIONS(i). In the example con- 
tained in Figure 38, there are no instructions on the 


aetriroute name. The function will evaluate to false. 
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b. Decoding the Attribute Instructions 

Next, each of the attributes will be checked to 
determine if there are instructions for decoding. The while 
EXECUTE AND DECODE(1) loop will continue to execute until 
all the attribute instructions have been decoded. The * and 
AGE attributes contained in the query have no instructions. 
These attributes cause the NO _INSTRUCTIONS(i) function to 
evaluate true and call the NO OP(i) procedure. The NO OP(i) 
procedure increments the global counter but does not write 
to the ESOL .query Varray. The second attribute, SNAME, 
causes the DOT P ON OPERATION function to evaluate true. 
The translator analyzes the instruction field of SNAME and 
determines a '.P' operation must be performed on SNAME. The 
RETRIEVE _SELECT(i) procedure is called, and SNAME is written 
to the select line. At this point, the first two lines@er 
the query have been formed, and the system could retrieve 
all of the STUDENT names from the STUDENT table. However, a 
condition still needs to be specified and the translation is 
still incomplete. Figure 40 shows the partially completed 
ERSOL query. 

The fourth attribute, GPA, is translated, and 
the INSTRUCTIONS ON _ATTRIBUTE(i) function evaluates true and 
calls the RELATIONAL OPERATORS procedure. This procedure 
translates the instruction field and determines that a legal 
operation, '>=' (greater or equal than), is to be performed 


on the integer 3.5. Since this operation represents’ the 


abil 


ESQCL ARRAY 


L SELaCT  sNaAns 





2 ROM SLUDENT 
3 ECSECECEES 


5 | @@GeCeeCeCe 


Figure 40. ESQL Array after Two Lines are Translated 


first condition of the query, the attribute operation is 
written to the third line of the query that will be composed 
of 'WHERE GPA >= 3.5'. Figure 41 shows the translated 
ESO. This partial query represents the first three lines 
of the ESOL translation. The final attribute to be decoded 
is MAJOR. The MAJOR attribute is a complex attribute of 
myipe DEPT. For the ESQL translation, the complex data type 
is represented like any other attribute in the ESQL query. 
The INSTRUCTIONS_ON_ATTRIBUTE(i) function is evaluated to 
maecweana Calls Che RELATIONAL OPERATORS procedure. the 
RELATIONAL OPERATORS procedure determines that a valid 
operation, ‘'=!' (equals), is to be performed on the MAJOR 
attribute. This operation will be translated to 'AND MAJOR 
= 'MATH' ' and written to the fourth line of the ESQL query 
array. Figure 42 displays the final ESQL translation after 


all attributes have been decoded. 


is 


ESQL ARRAY 
ul SELECT SNAMs 


zg FROM STUDENT 





4 | eeeeeeeeee | 


5  eeeeeeeeee 


Figure 41. ESQL Query with Three Lines Translated 


ESQL ARRAY 





hea) WHERE) Ghaw — 25 | 


a | AND MAJOR = 'MATH' | 


5  eeeeeeeeee | 
ae 
Figure 42. ESQL Array after Translation is Complete 
The ESOL query is ready to be translated to 
primitive SQL syntax for the final SQL query. The ESOL 


query shall be sent to the ESQL to SQL translator to 


accomplish the final translation. 
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4. BSsObe lO vse 

For the final translation, the ESQL to SQL trans- 
lator shall iterate through the query array and determine if 
a line contains a complex data type. The first four lines 
in the ESQL query can be substituted without change to final 
SQL query. 

The last line of the query has a non-atomic attri- 
bute type and a complex translation must occur. The SQL 
translator determines that MAJOR is not atomic by consulting 
a table that holds all complex data types. MAJOR is of type 
DEPT. The ESQL Line CONTAINS COMPLEX DATA(i) function 
Evaltates to true, and the procedure TRANSLATE ATOMIC DATA - 
CONSTRUCTS(i) will translate the final line to read 'AND 
DIDNAME = 'MATH' '. DIDNAME is an identifer of type string 
that will be compatible with primitive SQL constructs. 

The final step in the translation process is the 
procedure JOIN IDENTIFIER TABLES WITH OBJECT TABLE adding 
the identifier table, IDTOWN, to the FROM line. IDTOWN acts 
aS a surrogate table that is joined with the STUDENT table 
to indirectly represent complex data as atomic data. The 
completed SQL query is shown below in Figure 43. Now the 
SQL query can be delivered to the relational system to 
retrieve the desired student names. 

The results of the query will be returned to the 
translator in set type format and retranslated to object- 


Sriented format for user view. 


eS 


SQL ARRAY 





il SELECT SNAME 
_, FROM STUDENT, IDDEPT 


3. WHERE GPA >= 3.5 





| 4 . AND DIDNAME = 'MATH' 


a 


| 5  @eeeeeeeee 


Figure 43. SQL Array after Translation is Complete 
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The need for a user friendly graphics interface to the 
relational datavase system has been validated by examining 
the deficiencies and limitations of the current relational 
database systems. The deficiencies and limitations of these 
systems are caused by the relational model's lack of 
semantic capability. Relational systems lack semantic power 
because they are based on poor semantic data models. 
Systems that support specific higher level abstraction 
concepts have the power, flexibility and capability to 
provide a user friendly environment and extended relational 
capabilities. These systems should support aggregation, 
association, generalization and classification. 

Inadequate semantic capability is not the only reason 
that relational systems are not well suited for the entire 
population of database users. Moreover, standard relational 
query languages are untenable for naive and inexperienced 
database users. People who generally do not have formal 
computer education or training are often in administrative, 
Clerical and technical positions that require the use of 
computers to do their jobs. In fact, computer technology 
has experienced wide spread proliferation, and computers 
have permeated our society. Therefore, it is important that 


non-computer professionals who need computer technology to 
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perform every day job functions be given the best possible 
user interfaces for their working databases. 

Research has determined that the previously discussed 
relational query languages are entirely unsuitable for these 
types of individuals. Tuple calculus and relational algebra 
based systems may provide and effective user interface with 
QUEL and SQL for the mathematician or computer scientist. 
The mathematical query concepts can be associated by the 
user to already familiar math or computer concepts. Unfor- 
tunately, the naive user will probably not be familiar with 
these concepts. 

From a human factors design point of view, a system must 
provide the user with functional items that can be as= 
sociated to familiar concepts. Database entities and sub- 
entities can be effectively associated with simple graphics 
objects. GLAD utilizes rectangles and lines to make these 
correlations between the real world entity and abstract 


object. 


A. EXTENDING THE RELATIONAL SYSTEM 

More than a decade of arduous research has validated the 
existing relational database technology. Relational theory 
has provided a sound theoretical basis for the current rela- 
tional systems. It would be unwise to totally abandon this 
technology and start from ground zero to develop a new 
system. Perhaps, a major technological break through in 


computer architecture would merit a complete database system 
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redesign. Furthermore, most of today's database technology 
is based on research that was done nearly 20 years ago at 
IBM research center in San Jose, California. In addition to 
Codd's relational model, considerable advances were made in 
all aspects of database technology that are entirely 
relevant to today's systems. 
1. A Stable Database Technology 

Today, computers have become relatively inexpensive 
and have been designed to be easier to learn and use. 
Hardware component prices have consistently plummeted in 
value. In the last decade, memory has become orders of 
magnitude cheaper. Despite advances in both hardware and 
software, database theory has fundamentally remained consis- 
tent since the advent of the relational model. 

2. Extend Existing Database Technology 

Therefore, until a major technological break through 
has been accomplished, such as the development of an 
inexpensive secondary storage device that is orders of 
magnitude faster than disks, the wise approaches for 
improving database systems are centered around extending the 
existing data base technology. GLAD extends the existing 
relational system through graphical user interfaces that 
transport data and results to and from the relational 


system. 
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B. THE OBJECT ORIENTED SYsiew 

When implemented, GLAD's power, flexibility and user 
friendliness will provide the best possible interface to the 
user. Much of this capability is derived from the object 
oriented approach. ACTOR, the object oriented language used 
for GLAD implementation, will provide the window interfaces 
to the user. The capabilities of GLAD's user interfaces 
will be derived from ACTOR's object-oriented classes and 
methods. ACTOR's object oriented classes will supply GLAD 
with the graphical objects that represent the database. [In 
addition, GLAD shall utilize ACTOR's Collection descendants 
to define data structures that will effectively support the 
user interfaces. 

The relationship between ACTOR and GLAD is analogous to 
the relationship between SQL and embedded PL1 or Cobol. 
However, a major difference is that GLAD can be represented 


in a much more natural manner than SQL embedded in PL1. 


C. FUTURE GLAD APPLICATIONS 
GLAD has many potential uses for future applications. 
It has potential military, administrative, educational and 
training possibilities. The easy to use and learn inter- 
faces will make the system available to the widest range of 
database users. 
1. Military Applications 
GLAD has tremendous potential for a wide variety of 


applications. In particular, GLAD seems well suited to a 
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wide variety of military uses and applications. Military 
office usage of database could be aided significantly by 
providing good graphics interfaces to military administra- 
tive and data processing clerks. Military personnel often 
report to their commands and must be immediately integrated 
into the work environment without any significant on-the-job 
frarning. In addition, there are high turnover rates in 
most units due to transfers, discharges and reenlistments. 
Personnel must constantly be retrained on systems. GLAD 
could certainly help a clerk, that did not have computer 
experience, to quickly become a proficient database user. 

In a tactical environment, GLAD could be very 
valuable to the field commander. It could be used to 
formulate queries for portable PC based military data bases. 
Intelligence, logistic and historical information could be 
quickly accessed by troops and passed to their superiors for 
important tactical and strategic evaluation. 

2. Database Educational and Training Requirements 

GLAD could be useful as a tutorial for teaching 
naive users to use other database systems. Since GLAD is an 
extension of the relational database, a one-to-one corres- 
pondence can be established for the GLAD items that are 
substituted and translated to SQL items. This correspon- 
dence can be used to show the user, in piece meal fashion, 


how the GLAD query corresponds to the SQL query. 
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D. REMARKS ON IMPLEMENTATION 

GLAD implementation of graphics interfaces is an on 
going project with considerable work remaining in striking 
the ACTOR code for the higher level interfaces. However, 
much work has already been accomplished. In particular, the 
higher level abstractions have been formulated. Conceptual- 
ly, GLAD is entirely ready to be implemented. 

1. Mastering ACTOR 

The most si eater i came challenge to the implementors 

may be mastering the ACTOR programming language. The object 
oriented approach requires considerable departure from 
previous ways of forming code and writing programs. Many 
programmers have developed their programming strategies in 
ways that will require significant adaptation to object 
oriented format. Although ACTOR programs will generally be 
much shorter than a corresponding conventional, higher level 
language programs, the ACTOR code may actually require more 
thought than conventional code. The learning curve on 
object oriented concepts seems to be high. 

2. Interfaces and QueryCollections 

However, once these concepts are mastered, object 

oriented programming power can provide methods for graphical 
interfaces that can not be obtained with conventional 
languages. ACTOR maintains graphical methods, in a compact 
and precise manner, that are readily available with object 


oriented languages. ACTOR will be ideal for developing 
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methods and classes that will define the data structures 
that will support the ACTOR interfaces. The interfaces 
shall be a collection point for data, and QueryCollection's 
will serve as the transportation medium of this data to and 
from the user. 

3. The Bus Station Analogy 

The bus station analogy should prove to be useful in 
illustrating the interface implementations. A bus station 
can be thought of as a collecting point for people that need 
to ride the bus to a given destination. The query window is 
a collecting point for data that must ultimately be trans- 
ferred to the relational system and back to the user. The 
bus is the vehicle of transportation for taking the people 
to their destination. In fact, there are two types of 
buses: 

1. extended buses 
2. native buses. 

The pe cended buses take the people long distances 
from state to state and city to city. The native or local 
buses are driven by residents of the local community and 
take the bus riders, who have completed their extended bus 
ride, to the ultimate inner city or community destination. 
In other words, the native buses are short range buses, and 
the extended buses are long range buses. 

The methods that translate the GLAD query informa- 


tion to extended SQL information can be compared to the 
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extended bus that takes the user to the city of his inter- 
mediate destination. The methods that translate the 
extended £05 to native relational SCL can be compared to the 
native or local bus that takes the user to his ultimate 


destination. 


Be  EPVEOCUE 

The system formed from GLAD and a relational database 
will provide a powerful and easy to use interface to the 
widest possible audience of database users. GLAD represents 
the natural evolution of the relational system. In essence, 
the GLAD approach to database is evolutionary vice revolu- 
tionary. GLAD is not revolutionary because it does not 
propose a new database model with a new architecture to 
support the implementation. It is evolutionary because it 
takes a model that has already been validated and builds the 
interface on top of that model. In fact, GLAD could be 
implemented on the network, hierarchical and inverted list 
data models. Since GLAD is not based on any specific kind 
of model, it has a great deal of flexibility for serving as 
a bridge between the user and database. This approach has 
not been entirely explored and many systems based on this 
concept should be implemented before graphics extensions 
have been truly maximized as an effective man to machine 
interface. Until technology surpasses the capabilities of 


existing computer systems, the evolutionary approach 
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to designing new database systems will provide the highest 


yield for the least investment. 
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APPENDIX A 


A SIMULATED GLAD TRANSLATOR 


program ObjectTranalator; 


{ This program illustrates the use of the algorithm that 
will be used to translate object query windows to SQL 
syntax. The program is written in Borland Turbo 
Pascal 3.0 and executed on IBM compatible PC/XT micro- 
computer. 

FOR THESIS RESEARCH IN CONJUNCTION WITH GLAD 
Author Paul D. Grenseman, NPS/CS-71 - March 1988 } 


type 


OPERATION = string[16]; 
{ Used to hold relational operators for attributes 
or sub-objects that are queried } 


NAME = string[30]; 
{ Used to hold the NAME of the objects } 


OPERATIONS = array[1..10) of operation; 
{ attribute operations of the query } 


NAMES = array[1..10] of NAME; 
{ The NAMES of the objects that will be queried } 


INSTRUCTIONS = string[16]; 
{ INSTRUCTIONS to be performed on the entire 
object such as select all attributes or count 
all object attributes } 


ABOUT OBJECTS = record 
OBJECT NAME: NAME; 
OBJECT_INST: INSTRUCTIONS; 
end; 


ABOUT ATTRIBUTES = record 
ATTR_ NAME: NAMES; 
ATTR_OPERATION: OPERATIONS; 
end; 


PARTIAL QUERY = record 
OBJECT INFO: ABOUT OBJECTS; 
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ATTRIBUTES: ABOUT ATTRIBUTES ; 
1S QUERIED. boolean; 
end; 


{ A query that is not joined or completed. The 
user can elect to make a partial query complete 
by selecting the QUIT option } 


OBJECTS = record 

NAME: string[20]; 

SViIREEUDESGe array, |-.10)] ef string[20]; 
end; 

{ The Pascal simulation of the ACTOR object. 

< Object-declaration > ::= 
DEFOBJ < object _name > 
< attribute-declaration >+ 
ENDOBJ } 


OBJECT _QUERY_WINDOW = array([1..10] of PARTIAL QUERY; 
{ Partial Queries to be joined or nested } 


OBJ _ STR = string[40]; 


JOBS = (FACULTIES, SECRETARIES) ; 
{ Possible Employee Jobs } 


BEE SEY = (MATH, COMPUTER, MUSIC, PHYSICS, HISTORY); 
{ Departements the students can major in } 


BUERY STR = string(50]; 
{ One line of the TRANSLATED object query } 


eel QUERY = array([2..40] of QUERY STR; 
{ The translated sequel query in relation syntax } 


EXTENDED SQL QUERY = array({1..40] of QUERY STR; 
{ The translated object query in extended 
SQL syntax } 


const 
SENTINEL = '@@@@@GGGGG'; 
{ used during decoding process } 


var 
ITH ATTRIBUTE: integer; 
{ The Ith attribute in the query it is used to 
determine the placement of WHERE & AND } 


e, 


X: integer; 
{ Subscript for array of attributes } 


rey 


NO SELECTS: integer; 
{ Number of nested selects in partial query } 


1: integer; 
{ Loop control varlable@ser query | 


JOIN: boolean; 
{ Global boolean variable to indicate that 
objects in a query are joined } 


Es chaz. 

{ choose F or f to exit query process } 
FINISHED, 

{ FINISH set by f or F } 

MORE THAN: boolean; 

{ more than one sub-query } 


MAJOR, JOBTYPE, DEPT, MEMBERS, WORKSFOR: boolean; 
{ Used for decoding SET TYPES } 

NO PARTIAL QUERIES IN QUERY: integer; 

STUDENT QUERY, EMPLOYEE QUERY, COMMITTEE QUERY, 
FACULTY QUERY, 

{ Simulated Object Query display windows } 
PARTIAL QUERY OBJECTS: PARTIAL QUERY; 
OBJECT NAME STRING: OBJ_STR; 


FPACULTY, STUDENT, EMPLOYEE, COMM@UTLEE. obo HCrS. 
{ Simulated GLAD University DB Objects } 


QUERY: OBJECT QUERY WINDOW; 
{ The Completed Object Query to be translated} 


ERSQL: EXTENDED SQL QUERY; 
{ The Sequel Query with COMPLEX TYPES } 


SQL: SQL QUERY; 
{ The Translated Sequel Query in Relational format } 


FS@L: text? 


{ The text file that holds object, extended and 
relational queries } 


Ze 


precedure INITIALIZE GLOBALS; 
begin { INITIALIZE GLOBALS } 
{ Set all Gobal variables to initial values } 
ros 1; 
e:= 1; { All arrays subscript start at one } 
JOIN := false; 
MORE THAN := false; 
DEPT := false; MAJOR := false; WORKSFOR := false; 
JOBTYPE := false; MEMBERS := false; 
NO_ PARTIAL QUERIES_IN URES 2= 0; 
STUDENT.NAME := ! et 
COMMITTEE.NAME := ' Ue 
FACULTY.NAME := ' a 
EMPLOYEE.NAME := '! : 
Ber 1 := 1 to 10 de begin 
QUERY (2?) -lSpQUERIED -= false; 
SLUDENT. ATTRIBUTES |i) += * ore 
COMMITTEE HR ALT RIBULES [2] <= * oF 
PACULEY ATTRIBUTES |i .s— * i 
EMPLOYEE.ATTRIBUTES[i] := ' ne 
end; i fered += 1)to 10) do} 


for 1 3:= i to 40 do begin 
ERSQL[i] := SENTINEL; 
SQL{i] := SENTINEL; 

end; Goton ta s— 1 tO 40 do: ¥ 


end; { INITIALIZE GLOBALS } 


procedure LOAD OBJECTS; 
{ Simulated Objects loaded with attributes/sub-objects } 


procedure LOAD STUDENT; 

begin { LOAD STUDENT } 
STUDENT.NAME := 'STUDENT'; 
STUDENT .ATTRIBUTES [1] sey 


STUDENT .ATTRIBUTES[2] := 'SNAME!; 
SLUPENT Al TRIBUTES! 3) -—) ADDRESS’; 
STUDENT.ATTRIBUTES[4] := 'SSNO'; 
STUDENT.ATTRIBUTES[5] := 'GPA'; 
STUDENT.ATTRIBUTES[6] := 'MAJOR'; 


end; { LOAD STUDENT } 


procedure LOAD COMMITTEE; 
begin { LOAD_ COMMITTEE } 
COMMITTEE.NAME := 'COMMITTEE'; 


COMMITTEE.ATTRIBUTES[{1] := 'CNAME'; 
COMMITTEE.ATTRIBUTES[2] := 'MEMBERS '; 
COMMITTEE ATTRIBUTES (2)—:——)' PURPOSE"; 


end; { LOAD COMMITTEE } 
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procedure LOAD FACULTY; 
begin { LOAD FACULTY } 


FACULTY.NAME := 'FACULTY'; 
FACULTY.ATTRIBUTES[1] := 'FNAME'; 
FACULTY .ATTRIBUTES (2in— 1 AGE" 
FACULTY, ATTRIBUTES (21° — =’ Worker oa 


end; { LOAD FACULTY) 


procedure LOAD EMPLOYEE; 
begin { LOAD EMPLOYEE } 
EMPLOYEE.NAME := ‘EMPLOYEE'; 


EMPLOYEE.ATTRIBUTES[1] := 'ENAME'; 
EMPLOYEE.ATTRIBUTES[{2] := 'PAY'; 
EMPLOYEE.ATTRIBUTES[3] := 'DEPT'; 
EMPLOYEE.ATTRIBUTES[4] := 'JobType'; 


end; { LOAD EMPLOYEE } 
begin { LOAD OBJECTS } 


LOAD STUDENT; 
LOAD COMMITTEE; 
LOAD FACULTY; 
LOAD EMPLOYEE; 


end; { LOAD_OBJECTS } 


procedure LOAD WINDOWS WITH OBJECTS; 
{ Query windows loaded with object information } 


procedure LOAD STUDENT QUERY; 
var 
W: integer; 
begin { LOAD STUDENT QUERY } 
STUDENT QUERY.OBJECT INFO.OBJECT NAME 
STUDENT. NAME; 
STUDENT QUERY.OBJECT INFO.OBJECT INST 
t to 


STUDENT QUERY.ATTRIBUTES.ATTR NAME[1] 
STUDENT. ATTRIBUTES[1]; 

STUDENT QUERY.ATTRIBUTES.ATTR NAME[2] : 
STUDENT. ATTRIBUTES [2]; 

STUDENT QUERY.ATTRIBUTES .ATTR_NAME(3] 
STUDENT. ATTRIBUTES [3]; 

STUDENT QUERY.ATTRIBUTES.ATTR_NAME[4] 
STUDENT. ATTRIBUTES [4]; 

STUDENT QUERY.ATTRIBUTES.ATTR_NAME[5] 

STUDENT. ATTRIBUTES[5]; 
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STUDENT QUERY.ATTRIBUTES.ATTR NAME[6] := 
STUDENT. ATTRIBUTES [6]; 
STUDENT QUERY.IS QUERIED := false; 


fOr W t= 2..c6 6 do 
SLLUDENE Sere ATTRIBUTES.ATTR _OPERATION[W] := 


te 
’ 


end; { LOAD STUDENT QUERY } 


procedure LOAD FACULTY_QUERY; 
var 
W: integer; 
begin { LOAD FACULTY QUERY } 
FACULTY _ QUERY. OBJECT INFO.OBJECT NAME 
FACULTY. NAME; 
FACULTY QUERY.OBJECT_INFO.OBJECT_ INST : 
1 e 
FACULTY QUERY.ATTRIBUTES.ATTR NAME[1] 
PACULITY Alin puis | |; 
BACULTY POUERY ATTRIBUTES AlTTR NAME [2] 
FACULTY .ATTRIBUTES [2]; 
FACULTY QUERY.ATTRIBUTES .ATTR_NAME([3] 
FACULTY .ATTRIBUTES [3]? 
FACULTY QUERY.IS QUERIED := false; 
£Or W t= 1 to 3 do 
FACULTY LIE ATTRIBUTES .ATTR_OPERATION[W] : 


te 
, 


end; { Dan PRNCERN, UT } 


peocedure LOAD COMMITTEE QUERY; 
var 
W: integer; 
begin { LOAD COMMITTEE QUERY } 
COMMITTEE QUERY.OBJECT INFO.OBJECT NAME 
COMMITTEE .NAME; 
COMMETTERSOURRY.OBJECT INFO.OBJECT INST : 
' te 


COMMITTEE QUERY.ATTRIBUTES.ATTR_ NAME{[1] 
COMMITTER ALL REBUTES( 1); 

COMMITTEE QUERY.ATTRIBUTES.ATTR NAME[2] := 
COMMITTEE .ATTRIBUTES [2]; 

COMMITTEE QUERY.ATTRIBUTES.ATTR_NAME[3] := 
COMMELTEE. ALTRIBUDES | 3 |; 

COMMUTER ROURRY. TSeecURRIEDS:— false; 

for W t= 1 to 3 do 

COMMITTEE QUERY.ATTRIBUTES.ATTR OPERATION(W] := 
' fe 


end; { LOAD COMMITTEE QUERY } 
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procedure LOAD EMPLOYEE QUERY; 
var 
W: integer; 
begin { LOAD EMPLOYEE QUERY } 
EMPLOYEE QUERY.OBJECT INFO.OBJECT NAME := 
EMPLOYEE. NAME; 
EMPLOYEE QUERY.OBJECT INFO.OBJECT INST 
! es 


EMPLOYEE QUERY.ATTRIBUTES .ATTR_NAME[1] := 
EMPLOYER ALTREBULES (a); 

EMPLOYEE QUERY.ATTRIBUTES.ATTR_NAME[2] := 
EMPLOYEE.ATTRIBUTES [2]; 

EMPLOYEE QUERY.ATTRIBUTES.ATTR_NAME[3] := 
EMPLOYEE .ATTRIBUTES (24; 

EMPLOYEE QUERY.ATTRIBUTES.ATTR_NAME[4] := 
EMPLOYEE.ATTRIBUTES [4]; 

EMPLOYEE QUERY.IS QUERIED := false; 

for W := 1 to 4 do 

EMPLOYEE QUERY.ATTRIBUTES.ATTR OPERATION[W] := 
' Toe 


end; { LOAD EMPLOYEE QUERY } 
begin { LOAD WINDOWS WITH OBJECTS } 


LOAD STUDENT QUERY; 
LOAD EMPLOYEE QUERY; 
LOAD FACULTY QUERY; 

LOAD COMMITTEE QUERY; 


end; { LOAD WINDOWS WITH_OBJECTS } 


procedure DISPLAY QUERY OPTIONS; 

{ Screen Display that allows you to exit the query 
process or choose various query windows to be 
selected, nested, or joined } 


var 
SUBSCRIPT, COUNT, V: integer; 
0, OPTION: sechaxr; 
P; PARTIAL QUERY; 
S_ INST, €_ INST, E_ INST, Pernse 2 sootean, 
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procedure CLEAR (INST:boolean) ; 
{ Just blank Screen of old information } 
begin ( CLEAR } 
if INST then begin 
writeln; writeln; 
WEtee s( UREViEW YOUR OQUBRY AND HIT ENTER'’?:50) ; 
readin (Q); 
eclrscr; 
end, 8 INST = 
writeln; 
end; { CLEAR } 


procedure DISPLAY OBJECT INSTRUCTIONS( INST: BOOLEAN; 
DerPARTTALROQUERY ) ; 


begin { DISPLAY OBJECT INSTRUCTIONS } 

{ You may select special instructions '*' to select 
all attributes or 'COUNT(*)' to count all rows of 
object that meets specified conditions } 


if not INST then 
Wiedstee i ( | ts 248) 


else 
begin 
writeln (D.OBJECT_INFO.OBJECT INST: 22, 
t e'); 
writeln (FSQL, 
Dp ORJEGT INFO. GEdnGW™INST:22, " **); 
end; 


ema; { DISPLAY OBJECT INSTRUCTIONS } 


procedure DISPLAY ATTRIBUTE OPERATIONS ( INST: BOOLEAN; 
DD; PARTIAL OUERY ); 
begin { DISPLAY ATTRIBUTE OPERATIONS } 


{ Operations on attributes such as >, 
Will be displayed to user after they are typed in } 


a <= 


COUNT := COUNT + 1; 
if not INST then 
writeln('*':24 ) 


else 

begin 

writeln 
(D. ATTRIBUTES .ATTR_OPERATION[COUNT]:16, 
INT eo ed 
writeln (FSQL, 
D. ATTRIBUTES. ATTR OPERATION(COUNT]:16, 
Vesa eH 

end; 


Stichw Dil SPEAY ATTRIBULE OPERATIONS } 


{ The blank Query window is initially displayed 
to the user. He is asked to input instructions 
for objects and relational operations for 
attributes. To skip Object Instructions or an 
Attribute, hit enter. } 


procedure DISPLAY ESTUDENA, 
begin { DISPLAY STUDENT } 
COUNT := 0; 
if S_INST then 
begin 
STUDENT QUERY := P; 
writeln(FSQL, 
VHEKHKEKRKEKKRKKKKEKKKRKKRKRKKKKRKK 


KEKKKKKEK KEKE KREREKKEE' S60) 7 
write (FSOL,"* "107 

STUDENT QUERY.OBJECT_INFO.OBJECT NAME:25); 
writeln(FSOL," QUERY "7"**:18)> 
writeln(FSQL, 

LA KKKKKKKKKKKKKKKKKKK KER KEK 

KK KKK KK KK KKK KERR RERREEK' SEO) 7 
end; 
WLICESLN (HHH KHAHEKKKKKKKKKKKEKKKKKK 

KRKKK KKK KKK KK KKK KRKEREKKE'S 60); 
wreite( "2210, 
STUDENT _QUERY.OBJECT INFO.OBJECT NAME:25); 
wriltteln(* OUERY ©)  \''ea2).; 
WLICESLN (HH KKKKKHKKKKKKKKKHKKKKK KER 
Kk KKK KKK KKK KKK KKK RRR" 560) ; 

if S INST then 

write (FSQL, 

"e110, 

STUDENT QUERY.OBJECT_ INFO.OBJECT NAME:16, 

'e'S10); 


Write (01's 10? 
STUDENT_QUERY.OBJECT INFO.OBJECT NAME:16, 
veo)? 


DISPLAY OBJECT INSTRUCTIONS( S_INST, 
STUDENT QUERY ); 


if S INST chen 

write (FSQL, 

ee 

STUDENT QUERY.ATTRIBUTES.ATTR NAME[1]:6, 
0) 
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WELCe Se 0, 

STUDENT QUERY .ATTRIBUTES .ATTR_NAME([1]:6, 
coe One 

DISPLAY ATTRIBUTE OPERATIONS( S_INST, 
STUDENT CUERY™) 


if S_INST then 

write (FSQL, 

Ex LO, 

STUDENT QUERY.ATTRIBUTES.ATTR_NAME[2]:7, 
re 1S) 5 


Witten! +4 sO), 

STUDENT QUERY .ATTRIBUTES .ATTR_NAME[2]:7, 
eo) 

DISPLAY ATTRIBUTE OPERATIONS( S_INST, 
STUDENT SZOUEBRY );7 


if S_ INST then 

write (FSQL, 

Pe Ns LO, 

STUDENT SOUERY ATTRIBUTES -ATTR NAME(S] <9, 
US a Ue 9) 


Welcome '=10, 
STUDENT QUERY.ATTRIBUTES.ATTR_NAME[3]:9, 
Peli 


DISPLAY ATTRIBUTE OPERATIONS( S_INST, 
STUDENT QUERY ); 


if S_ INST then 

write (FSQL, 

take tee EO 

STUDENT QUERY .ATTRIBUTES.ATTR_NAME[4]:6, 
Ue 2 OO)? 


Write ('*' 210, 
STUDENT QUERY.ATTRIBUTES .ATTR_NAME[4]:6, 
Use 0). - 


DISPLAY ATTRIBUTE _OPERATIONS( S_INST, 
STUDENT QUERY ); 


if S INST then 

write (FSQL, 

'e'310, 

SLUDENT QUERY (ATTRIBUTES ATT RENAME (S]:5, 
3 Ue 


L335 


WELEe e's oF 
STUDENT QUERY . ATTRIBUTES -AlTARSNAME > |. 5, 
ew ie 


DISPLAY ATTRIBUTE OPERATICNS (= cmtlisL, 
STUDENT QUERY ); 


if S INST then 
write (FSQL, 


Pes Oe 
STUDENT _QUERY.ATTRIBUTES.ATTR_NAME[6]:7, 
Pe ES 


write ('*':10, 
STUDENT _QUERY.ATTRIBUTES.ATTR_NAME[6]:7, 
Wee ES ey 
DISPLAY ATTRIBUTE OPERATIONS( S_INST, 
STUDENT QUERY ); 
if S INST then 
begin 
writeln(FSQL, 
VaekaeKKKKKKKKKKKKKKKKKKKRKEEK 
RRKKKKKKKKKEKRKKRKRKKKKKRKKRKKKK! 360) ; 
writeln(FSQL) 
end; 
WLLCE|LN (HERA HRRHEKKKRRKKRKREKKEKEKE 
RRKKKRKKKRKKAKKKRKKKRKKEKKKRKEKKEK' 360) ; 


if S_INST then begin 


SUBSCRIPT :— JSUBSCR UP ae, 
QUERY [SUBSCRIPT] := STUDENT _ QUERY; 
QUBRY (SUBSCRIPT). IS7OURRE DD. struc, 


end; { if S_INST } 


CLEAR (S_INST); 
P := STUDENT QUERY; 


end; { DISPLAY STUDENT } 


procedure DISPLAY EMPLOYEE; 
begin { DISPLAY EMPLOYEE } 
COUNT := 0; 
if E_INST then 
begin 
EMPLOYER QUERY <= P; 
writeln( FSQL, 
Px KKKKKKKKKKKKKKKKKKKKKKKEK 
KKKKKKKKKKKRKKKKKKKRKKKRKKEKKEE' S60) 7 
write ( FSQL, 
Beer 
EMPLOYEE QUERY.OBJECT INFO.OBJECT NAME:25) ; 
writeln( FSQL, 
" QUERY ') 138); 
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writeln( FSQL, 
CReKKKKKKKKKKKKKRKEKKKEEEE 
KKKKKKEKKKKKKKEK KR RK RK KKEKREE'N SEO) 7 
end; 
WOLCSLM (RRR RRAKKRRAKRRAEKRRK EKER KK 
KREEKKEKKKKEKRKEKKKEKKKKKRKEKRKEREKE! 760) 4 
Writer x": 10, 
PMPECY EE VOUERY; OBJECT INrO. OBJECT NAME? 25) ; 
WElLtelig sOURRY "Le ) 7 
WLLCELN (  HHKKKKKKKERKEKRKRKKKERERK KK EK 
KEKKKKRKRKEKEKEKERKEKERREKEKKREREREK! 760) . 


ith INSP ecthen 

write (FSQL, 

De LO) 

EMPLOYEE QUERY .OBJECT INFO.OBJECT NAME:16, 
Mets 1 ODP: 


WEI te ses: 10; 
PMPEOY EET CUBRY -OBIECT INPO.OBJECT NAME: 16, 
ICO Nee 


DISPLAY OBJECT INSTRUCTIONS( E_INST, 
EMPLOYEE QUERY ); 


Tf HOES then 
write (FSQL, 


ee Or, 
EMPLOYEE QUERY.ATTRIBUTES.ATTR NAME[1]:7, 
et leo)? 


Welces(! e510) 
EMPLOYEE QUERY.ATTRIBUTES.ATTR_NAME[1]:7, 
pect) s 


DISPLAY ATTRIBUTE OPERATIONS( E_INST, 
EMPLOYEE QUERY ); 


if E_ INST then 

write (FSQL, 

ran. 10, 

EMPLOYEE) QUERY. ATTREBUTES ALT RENAME (2)]:5, 
ee een Ue 


weite. { AsO. 
EMPLOYER QUERY “ATTRIBUTES. ALTER ONAME (21:5, 
ees); 


DISPRAYSATTRIBUTE OPERATIONS( E INST, 
PVMPEOVEESQUERY ) 7 


Ales 


if E_INST then 
write (FSQL, 


Cn On 
EMPLOYEE QUERY .ATTRIBUTES-ATTR NAME 2] -6, 
Pes 2 Ola; 


write ('*'=:10. 

EMPLOY EEQUERY -ATTRIBUTES 2ou PR UNAMER 29-6, 

hae 20s 

DISPLAY ATTRIBUTE OPERATIONS( E_ INST, 
EMPLOYEE QUERY ); 

if EOENS) then 

write(FSQL, 

Wie) lil). 

EMPLOYEE QUERY .ATTRIBUTES.ATTR_NAME[4]:9, 

ll LP) 


write ('*' 310, 
EMPLOYEE QUERY .ATTRIBUTES.ATTR_NAME[4]:9, 
Pete 7 ee 


DISPLAY ATTRIBUTE _OPERATIONS( E_INST, 


EMPLOYEE QUERY ); 
if E_INST then 


begin 
writeln(FSQL, 
Ue KeKKEKKKKKKKKKKKKKRKKKKKKEKEKEE 
KeEAEKKKKKRKRRKRAKKKRKRK KKK :60) . 
writeln(FSQL) ; 
end; 


WLACSL MT ( HERRERA KAKAK KERR RE RK EKER 
KHEKKKEK KK KEKKKEKRK KKK KEK KR RKEEK' S60) 5 


if E_INST then begin 


SUBSCRIPT := SUBSCRIPT + 1; 
QUERY [SUBSCRIPT] := EMPLOYEE QUERY; 
QUERY [SUBSCRIPT].IS QUERIED := true; 


end; { if E_INST ) 


CLEAR (E INST); 
P := EMPLOYEE QUERY; 


end; { DISPLAY EMPLOYEE } 


procedure DISPLAY SrACuUETY, 
begin { DISPLAY FACULTY } 
COUNT := 0; 
if F_INST chen 
begin 
PACULTY SOUERY = — oe, 
writeln(FSQL, 


ALS) 


DTK KKKKKKKKHHKKKKKEKKKKKKEEK 
KRKKK KKK KKK KKK KR KKK KERR E'S EO) 7 
write GES5OL,. "= !s 10, 
FACULTY QUERY.OBJECT INFO.OBJECT NAME: 25); 
writeln(FSQL, 
' QUERY ','*':18); 


writeln(FSQL, 
DTK KKK KHKKHKKHK KKK KKKRKEKKEEE 


KKK KKKKKKKKRKRKKKRKKEEEEK' SEC) 7 
end; 
WLLCESLN (RHR HKHRAKE KKK KR KRKE EEK 
KEKKKKKKRKKKKKRKKRKRKKKKKEKKKE'. G60) 3 
Write ("**:10, 
EAGUDIY  OURRY SORT ECE SINT OSOBIJ ECT NAME: 25); 
Wrlbeln MeOURRY "4's 18)". 
WLAICESLN (RHE HRKERKKHRKKERKKERK KKK ER 
KHRKKKKKKKKKKKKKKKKKKRRERKEE' S60) 7 


eh eeNST then 
write (FSQL, 


ers LO; 
FACULTY _QUERY.OBJECT_INFO.OBJECT _NAME:16, 
USD ae 


White ('*':10, 
FACULTY QUERY.OBJECT_INFO.OBJECT NAME:16, 
Px VO) 7 
DISPLAY OBJECT INSTRUCTIONS( F_INST, 
FPACULEY QUERY )7 

if F_INST then 
write (FSQL, 


Pete 10; 
FACULTY _QUERY.ATTRIBUTES.ATTR NAME[1]:7, 
Bos OF) 


Wreice ('*": 10, 
PACULTY QUERY -ATTRIBUTES -ATTR NAME(IJ:7, 
A oe: 
DISPLAY ATTRIBUTE _OPERATIONS( F_INST, 
FACULTY QUERY ); 

if F_INST then 
write (FSQL, 


ox 10, 
FACULTY QUERY .ATTRIBUTES.ATTR NAME[2]:5, 
Gee 


write ('*1:10, 
PACUILTEY QUERY -ATTRIBUPES .ATTR NAME([2]:5, 
er es ea 
DISPLAY ATTRIBUTE _OPERATIONS( F_INST, 
FACULTY QUERY ); 
if F_INST then 
write (FSQL, 
ret. 10. 
RAGULITY QUERY “ATTRIBUTES-ATTR NAME[3]:10, 
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'e'316); 
Write "(472107 
FACULTY QUERY . ATTRIBUTES SATII R NAME 3 ) > 107 
nh Mone, 
DISPLAY ATTRIBUTE VOEERATIONS (Sige loi, 
FACULTY QUERY i; 
if FlUINSE eden 
begin 
writeln(FSQL, 
VKH KKK KKKKKEKKKKRKEKKKK KKK 
RRKKKKKKKKKKKKKKKKKRRRKREREE' S60) 7 
writeln(FSQL) ; 
end; 
WLItC|LN (HER KKRKKKRKKKERKKKERKEKEKKKR 
RRKKKKKKKKKKKKRKKKRKRRKKKRREE' S60) 7 
writeln; 


if F_INST then begin 
SUBSCRIPT =— SUBSCRIPT +; 
QUERY [SUBSCRIPT] := FACULTY GUERY; 
QUERY [SUBSCRIPT].IS QUERIED := true; 
end? (te ve itiois, 


CLEAR(F_INST); 
P := FACULTY QUERY; 
end; { DISPLAY FACULTY } 


precedure DISPLAYS COMMiITTEn, 
begin { DISPLAY COMMITTEE } 
COUNT := 0; 
if C_INST then 

begin 
COMMITTEES OGUERY <=32; 
writeln(FSQL, 

KHEEKKKEKKEKKEKKKREKEKKKKKEKKEE 
RRKKKKKKKKKKKKKKKRKKRKKREKEKE'S E60) 7 

write (FSQL, 
be suai ig 8 1 
COMMITTEE QUERY.OBJECT INFO. OBJECT NAME. 255 
writeln(FSQL, 
SOUR RY es ' 213 jie 
writeln(FSQL, 
PR HKKKKEKKEKKKKKEKKRKKRKEKKEKRKRKEKKEEKK 
RRKKKKKKKKKKKKRKKKRRKRKRRRER' S60) 7 

end; 

WLLt|LN (RHR KKKRAEKKKKKEKKKEKKKKKKE 

KRRKEKKKKKKRKKKKRKKKRKKRRREREE'S 60) 7 

Write) ('*t 2107 

COMMITTEE QUERY.OBJECT_ INFO.OBJECT NAME: 25) ; 

writeln(! QUERY ';?* 1718); 

WLLCESLN( | HHKKKKKKKKKKKKKKKK KKK KKK 

KHKKKKKKKKKKRKKKKRKRKRRKREKKEEE' 3 60) 7 
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if C_INST then 
write (FSQL, 
'e':310, 
COMMEETEER CUBR Y. OBJECT tINFO-OBJECT NAME: 16, 
Ee eo) yrs 
Weles (aac. 
COMMIT Tae OUERY. CEIECT INTO. OPJECT NAME 16, 
\ 2 ale 
DESPLAY (OBI ECT INSTRUCTIONS ( C INST, 
COMMITTEE QUERY )7 

if C_INST then 
write (FSQL, 


eee nO’, 
COMMITTEE QUERY.ATTRIBUTES.ATTR NAME[1]:7, 
Wey bales ke 


Wises fete: dO 
COMMITTEE QUERY.ATTRIBUTES.ATTR_NAME[1]:7, 
yeas S) )) 


DISPLAY ATTRIBUTE OPERATIONS( C_INST, 
COMMITTEE QUERY ); 

if Cc_INST then 

write (FSQL, 


Te Sabah 
COMMITTEE QUERY.ATTRIBUTES.ATTR NAME[2]:9, 
ee al 


Write (eu. NOR 
COMMITTEE QUERY.ATTRIBUTES.ATTR_ NAME[2]:9, 
Ee i 
DISPLAY ATTRIBUTE OPERATIONS( C_INST, 
COMMETTBESSUERY 9s; 

tec ENGI then 
write (FSQL, 


Pe LO. 
COMMITTEE QUERY.ATTRIBUTES.ATTR NAME[3]:9, 
Oe LT yas 


write ('*':10, 
COMME TITER QUERY -ATTRIBUTES-ATTR NAME[3]:9, 
ata 7) + 
DISPLAY ATTRIBUTE OPERATIONS( C_INST, 
COMMITTEE QUERY ); 
tec INST then 
begin 
writeln(FSQL, 
Cee KekekKekKeKekeaeKeKeKKRK KKK KKK 
kaekkekaeeaekeeereaeKeerKeRRKRKR KKK >60) . 
writeln(FSQL) ; 
end; 
writeln( VekekekekKekekeKekeeKRKRKRKRKKRKKRKRKKRKRKE 
kkekekkeeKeeKeRKRK KKK KKK KRKRKRKRKKEK 760) . 


writeln; 


141 


if C_INST then begin 


SUBSCRIPT := SUBSCRIPT + 1; 
QUERY [SUBSCRIPT] := COMMITTEE QUERY; 
QUERY [SUBSCRIPT]. 132 QUERTED: — crue, 


end; { if C_INST ) 


CLEAR(C_INST) ; 
P 3>= COMMITTEE TOURER: 
end; { DISPLAY COMMITTEE } 


procedure GET INSTRUCTIONS (Var P: PARTIAL QUERY) ; 
var 
w: integer; 
begin { See Ue Sous } 
write ('INPUT INSTRUCTIONS FOR OBJECT ‘); 
write (P.OBJECT INFO.OBIECT Name, ": 9"); 
readin ( P. OBJECT INFO.OBJECT INST) ; 
for w t= 1 to 3 edempeqm 
write ('INPUT INSTRUCTIONS FOR ATTRIBUTE ', 
P.ATTRIBUTES.ATTR_NAME[w], ': eee 
readln (P.ATTRIBUTES.ATTR OPERATION [w]) ; 
end; { for w += 1 to 33} 


'EMPLOYEE') or 
'STUDENT') then 


if (P.OBJECT INFO.OBJECT NAME 
(P.OBJECT INFO.OBJECT NAME 


begin 
write ('INPUT INSTRUCTIONS FOR ATTRIBUTE ', 
P, ATTRIBUTES. ATTRENAME aay nt) > 
readln (P.ATTRIBUTES.ATTR_OPERATION[4]); 
end; { P NAME = 'EMPLOYEE or STUDENT' } 
Lf Cee OBJECT _INFO.OBJECT NAME = 'STUDENT') then 
begin 
write ('INPUT INSTRUCTIONS FOR ATTRIBUTE ', 
P.ATTRIBUTES.ATTR_NAME[5], ': '); 


readin (P.ATTRIBUTES.ATTR OPERATION[{5]); 
write ('INPUT INSTRUCTIONS FOR ATTRIBUTE ', 


P.ATTRIBUTES.ATTR_NAME[6], ': PNG 
readin (P.ATTRIBUTES.ATTR_ OPERATION([6]) ; 
if P.ATTRIBUTES -ATTR: OPERATION G] == '" ther 
MAJOR := true; 
end; { P = STUDENT QUERY } 
if (P.OBJECT INFO.OBJECT NAME = 'COMMITTEE') then 
if P.ATTRIBUTES.ATTR _OPERATION[2] <> '' then 
MEMBERS := true; 
if (P.OBJECT INFO.OBJECT NAME = “FACULTY \)Schen 
if P. ATTRIBUTES. ATTR OPERATOR | <->! =e enen 
WORKSFOR := true; 
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if oP OBJECT INFO OBg ECT NAME S— "EMPLOYEE') then 


begin 
Le P.ATTRIBUTES.ATTR_OPERATION([3] <> 
DEPT := true; 
it P. ATTRIBUTES; ATTR_OPERATION(4] <> 
JOBLTYPE := true; 
end; 


@lESer. 


ene, GEL INSTRUCTIONS } 


procedure SHOW _USER_HIS_ ENTRY; 
begin { SHOW _USER_HIS ENTRY } 
case OPTION of 
's', 'S': began 


'' then 


Ut jehaw=nel 


S_INST := true; 
STUDENT _QUERY.IS_ QUERIED : 
ie Tees, 
DISPLAY STUDENT; 
SeiNSst := talse; 
end; 
'e' ,'E': begin 
E_INST := true; 
EMPLOYEE QUERY.IS_QUERIED 
eee: 
DISPLAY EMPLOYEE; 
E_INST := false; 
end; 
Seer begun 
F INST = true; 
PACULLY OUBEY ES SOUERTED : 
true, 
DISPLAY FACULTY; 
PRENSDT | calse; 
end; 
Vem 'c': begin 
CeINST eS. = erue; 
COMME OURRY iS ,OUERTED s= 
crue; 
DISPLAY COMMITTEE; 
C INST := false; 
end; 


end; { case OPTION of } 


end; { (SHOW USER THI SSENTRY } 
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begin { DISPEAY QUERYUOETUI@HS)) 


SUBSCRIPT := 0; 
S INST := false; E_INS 
F INST := false; C_INS 
cirser-> 
for V t= 1 9to 5 de vereotn 
while ( OPTION <= 'O")) and) ( OPTION <>" q) jade 
begin 
writeln (‘ENTER “S" FORPS PUDENT CURR Wa): lia, 
writeln; 
writeln (‘ENTER “E" FOR EMPLOYEE QUERY!:52); 
writeln; 
writeln (*ENTER UE" PORSE ACs @ Wir yates dja. 
writeln; 
writeln ('ENTER "C" FOR COMMITTEE QUERY':53); 
writeln; 
writeln (‘ENTER "“O" TO OULD eserEreTroN 51); 
writeln; 
Write (') '2 3a). 
readln (OPTION); 
writeln; 
clrscr; 


alse; 


. 225 
T := false; 


case OPTION of 
's',"S': DISPLAY STUDENT; 
"e', 'E. DISPREAY SEMPUOYEE, 
'f',  F 2 DISPLAY ar eerie, 
"oc! , 'C!s DISPLAY (COME rine, 
end; { case OPTION of } 


if ( OPTION <> "O") and ( ObUloN <5 q's) then 
begin 

GET INSTRUCTIONS (P) ; 

SHOW_USER_HIS_ENTRY; 
end; { if OPTION } 

for V := 1¥to 5 do writeln- 


end; { while OPTION <> 'q' anda o =) 


end; { DISPLAY QUERY OPTIONS } 


procedure HOW_MANY PARTIAL QUERIES( Var PARTIALS: 


integer); 
begin { HOW MANY PARTIAL QUERIES } 
PARTIALS := 0; 
while QUERY[PARTIALS + 1].2S QUERIED do 
PARTIALS := PARTIALS + 1; 
end; { HOW_MANY PARTIAL QUERIES } 
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function MORE THAN ONE OBJECT USED _IN QUERY: boolean; 
var 
ie Integer: 


begin { MORE THAN ONE OBJECT USED IN_ QUERY } 
i — (> 
while QUERY[i + 1]-IS_QUERIED do 
= et 1 
MORE THAN ONE OBJECT USED _IN QUERY := (1 < i ); 
end; { MORE THAN ONE OBJECT USED IN QUERY } 


procedure SELECT(k: integer) ; 
{ Analogous to Relational SELECT 
Substituted for Object .P } 


begin VeSHLEecr a) 
ERSQL[K] := 'SELECT '; 
end; (SELECT } 


procedure FROM(j,k: integer) ; 
{ Analgous to Relational FROM - Object Name } 


begin { FROM } 

ERSQL[kKk] := 'FROM ' + 

QUERY [j]-.OBJECT INFO.OBJECT NAME; 
end; { FROM } 


Praeacedure JOIN OBJECTS? 

{ Unless * is used for attribute name, the selection 
of more than one object window implicitly specifies 
a join of Tables } 


begin  aiOuNe ey 
case NO PARTIAL QUERIES _ IN QUERY of 
Poe Roo 2) >— se RSOL| Zier, * soe 
QUERY [2].OBJECT_INFO.OBJECT_ NAME; 
2) BPRoOUIZ eek oOL| Zit  *, * 
QUERY [(2].OBJECT_INFO.OBJECT NAME 
+)", © to (OUERY [3 | OBI ECT RINEO.OBJECT NAME; 
4: ERSQL[2] := ERSQL[2] + ', ' + 
QUERY[2].OBJECT INFO.OBJECT NAME 
+ ee eect QUERY[3]. CEuners INFO.OBJECT NAME 
+ Yb ees QUERY (4). OBJECT INFO. SEsnenm NAME; 
end; { case NUM PARTIAL QUERIES IN QUERY or |} 
JOIN := true; 
end; { JOIN } 


function INSTRUCTIONS ON OBJECT NAME(i:integer) :boolean; 
begin { INSTRUCTIONS _ON_OBJECT NAME } 
INSTRUCTIONS _ON_ OBJECT NAME := 
ee Se QUERY[i]. OBJECT INFO.OBJECT men St ( 1); 
end; { INSTRUCTIONS ON OBJECT NAME } 
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procedure OBJ OPERATIONS(i: integer); 


begin { OBJ_OPERATIONS } 
if ( ERSQL{1] = 'SELECT ') and 
( QUERY[i].OBJECT INFO.OBJECT INST = '*' ) then 
ERSQL{1] := ERSQL{1] + 
QUERY{i].OBJECT INFO.OBJECT NAME + '.!' + 'x! 
else if ( ERSQL{1] <> 'SELECT ') and 
( QUERY[{i].OBJECT INFO.OBJECT INST = '*' ) then 
ERSQL[1] := ERSQL[1] + ', ' + 
QUERY[{i].OBJECT INFO.OBJECT NAME + '.' + '! 
else if ( ERSQL{1] = 'SELECT ') and 
( QUERY[{i].OBJECT INFO.OBJECT INST = 'COUNT' ) 
then ERSQL[1] := ERSQL[1] + "COUNT(*)'! 
else if ( ERSQL(1] <> ‘SELECT ') and 
( QUERY[i].OBJECT INFO.OBJECT INST = 'COUNT' ) 
then ERSQL[1] := ERSQL{1] + ', ' + 'COUNT(*)'; 
end; { OBJ_OPERATIONS } 


function EXECUTE AND DECODE(i: integer): boolean; 
{ Global counter X is used to step through all of 
the attributes until the query window is decoded 
and translated to ERSQL } 
begin { EXECUTE AND DECODE } 
alge QUERY[i]-OBJECT_INFO.OBJECT NAME = 'STUDENT' 
then EXECUTE _AND DECODE := ( X < 7 
else if QUERY[{i].OBJECT INFO.OBJECT NAME = 
"EMPLOYEE' then 


EXECUTE AND DECODE := ( X < 5 ) 
else EXECUTE _AND_ DECODE := ( X < 4 ); 
end; { EXECUTE _AND DECODES 


function ASTERISK_FOR_ATTRIBUTE NAME(i: integer) : 
boolean; 
{ Selection of * attribute indicated a nested query } 
begin { ASTERISK FOR_ATTRIBUTE_NAME } 
ASTERISK FOR _ ATTRIBUTE NAME := 
QUERY[i]. . ATTRIBUTES.ATTR _NAME[X] = '*!'; 
end; { ASTERISK FOR ATTRIBUTE NAME } 


function EXISTENTIAL QUANTIFIER(i: integer): boolean; 
{ Used with nested queries } 
begin { EXISTENTIAL QUANTIFIER } 
EXISTENTIAL QUANTIFIER := 
(QUERY [i] .ATTRIBUTES.ATTR_OPERATION[X] =SEXESTS ”) 
or (QUERY [{i].ATTRIBUTES.ATTR OPERATION [{X] = 
'NOT EXISTS'); 
end; { EXISTENTIAL QUANTIFIER } 
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function DOT P ON ATTRIBUTE(i: integer) :boolean; 
Melnatcates print or .P = SELECT attribute } 
var 

REMP: string(30]; 


begin (Oe TP LONTAT ERI BUTE | 
meMP s= ''; 
TEMP := GUERY [2] ALTRIBUTES-ATTR OPERATION ( X]> 
BOD P ON ATTRIBUTE s= ( (TEMP[1] = '.*) and 
GLEMP(2] = "P") ); 

end; Velo Ree ChAT ET BUTE} 


procedure RETRIEVE SELECT(i: integer) ; 
{ Checks to see what is selected } 
procedure CHECK OPS (i: integer; COMPARE: NAME) ; 
{ Allows attribute with mathematical operation 
to selected DISTINCT, COUNT, or other 
AGGREGATE Ops } 
begin { CHECK OPS } 
if ( COMPARE[1] in ['t', '-', '*', '/']  ) then 
ERSQL{1] := ERSQL[1] + 
QUERY (i].ATTRIBUTES.ATTR_NAME[X] 
+ COMPARE 
else if COMPARE = '' then 
ERSQL[1] := ERSQL{1] + 
QUERY(i].ATTRIBUTES.ATTR NAME[X] 
else if COMPARE = 'DISTINCT! then 
ERSOCG Mie -— EksOli ie. “DistTiIner * 
+  QUERY([i].ATTRIBUTES.ATTR_NAME[X] 
else if COMPARE = 'COUNT! then 
ERSQL[1] := ERSQL[1] + 'COUNT(' 
+ QUERY [i].ATTRIBUTES.ATTR NAME[X] 
di oye 
else if COMPARE = 'SUM' then 
ERSQL[1]:-:= ERSQL[1] + 'SUM(' 
+ QUERY(i].ATTRIBUTES.ATTR_NAME[X] 
+ nyt 
else if COMPARE = 'AVG'! then 
ERSQL[1] := ERSQL[{1] + 'AVG(' 
+ QUERY [i].ATTRIBUTES.ATTR_NAME[X] 
dt. Ht 
else if COMPARE = 'MAX'! then 
ERSQL[1] := ERSQL[1] + 'MAX(' 
+ QUERY[i].ATTRIBUTES.ATTR NAME[X] 
o a 
else if COMPARE = 'MIN'! then 
ERSQL[1] := ERSQL[1] + 'MIN(' 
+ QUERY[i].ATTRIBUTES.ATTR NAME[X] 
+ ve eae 
end; { CHECK OPS } 
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var 
COMPARE: NAME; 


begin { RETRIEVE SELECT } 

COMPARE == 1°. 
COMPARE := 
copy (QUERY[i].ATTRIBUTES.ATTR_OPERATION[X],4,27); 
if ( MORE THAN ) or 

( INSTRUCTIONS ON OBJECT NAME(i) ) then 

begin { if MORE THAN } 

ERSOL{1] := ERSQL[1] + ', '3 


CHECK OPS “( ieeMPARE a 
end { if MORE THAN } 
else if not MORE _THAN then 
begin { if not MORE THAN } 
CHECK OPS (i, COMPARE) ; 
end; { if not MORE THAN } 
MORE THAN := true; X := X + 1; 
end; { RETRIEVE SELECT } 


function NO _INSTRUCTIONS(i: integer): boolean; 
begin { NO_INSTRUCTIONS } 
NO_INSTRUCTIONS := 
QUERY[i] .ATTRIBUTES.ATTR_OPERATION[X] ee 
end; { NO_INSTRUCTIONS } 


procedure NO OP( i: integer); 

begin { NO_OP } 
{ DOES NOTHING BUT IS USED TO ILLUSTRATE THE MAIN } 
{ LOOP'S ALGORITHM FOR DECODING THE OBJECT QUERY  } 
X 3s] Xo 1 

end; { NO_ OP } 


function INSTRUCTIONS ON ATTRIBUTE(i: integer): boolean; 
begin { INSTRUCTIONS ON ATTRIBUTE } 
INSTRUCTIONS ON ATTRIBUTE := 
QUERY[i].ATTRIBUTES .ATTR OPERATION[X] <a 
end; { INSTRUCTIONS ON ATTRIBUTE} 


procedure RELATIONAL OPERATORS; 


var 
TEMP: string[(30]; 

begin { RELATIONAL OPERATORS } 

TEMP := QUERY{i]-ATTRIBUTES.ATTR_OPERATION[X]; 
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if TEMP[1] in ['>','<','="'] then 
begin { if TEMP[{1] } 
if ( ERSOL[e+2] = SENTINEL ) then 
begin { ERSQL[e+2] = SENTINEL } 
ERSQL[e+2] := 'WHERE ' 

+ QUERY({i].ATTRIBUTES.ATTR NAME[X] 
= 0 0 oe geahiuer 

end  ( ERSQL[e+2] = SENTINEL } 


else 
begin { ERSQL{e+2] <> SENTINEL } 
ERSQL[e+3] := 'AND : 
+ QUERY[(i].ATTRIBUTES.ATTR_NAME[X] 
+ ' ' + TEMP; 
e:=ert+l1; 
end; { ERSQL[et+2] <> SENTINEL } 
end  { if TEMP[1] } 
else 
begin { else } 
if ( ERSQL[e+2] = SENTINEL ) then 
begin { ERSQL[e+2] = SENTINEL } 
ERSQL[e+2] := 'WHERE ' 
de QUERY[i].ATTRIBUTES.ATTR_NAME[X] 
+ ' SYNTAX ERROR W/REL OP'; 
e := e+ 3; 
end { ERSQL[e+2] = SENTINEL } 
else 
begin { ERSQL[e+2]} } 
ERSQL[e] := 'AND ' 
ae QUERY(i].ATTRIBUTES.ATTR_NAME[X] 
aF ' SYNTAX ERROR W/REL OP'; 
e :=ert+ il; 
end; { ERSQL[e+2] <> SENTINEL } 
end; { else } X := X +1; 
end; { RELATIONAL OPERATORS } 


procedure SPECIAL OPS(i: integer); 


begin { SPECIAL OPS } 
e 3:= 3; 
ERSQL[2] := 'FROM r+ 
QUERY [1].OBJECT INFO.OBJECT NAME; 
Sw QUERY[1].ATTRIBUTES.ATTR OPERATION ([X] = 'EXISTS' 
then ERSQL[e] := 'WHERE EXISTS'; 


fPeToUERY (1) ATTRIBUTES -ATTR OPERATION (xX ] 
NOT EXiSTS* then 
ERSQOL[(e] := 'WHERE NOT EXISTS'; 
e :=ert+ 1; 
Beeompel t= “(sELECT =}; 
BROM(i,etl); Xae= X + 17 
end; feel herAEROPS 
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procedure ESQL VIEW; 
var 
1: integer; 
LEFT PAREN: boolean; 
TEMPS serine ocr 
begin { ESOU VIEWS) 
i= ae 
LEFT PAREN == false; 
while ERSQL[i] <> SENTINEL do 
begin { ERSQL[i] <> SENTINEL } 
TEMP := ERSQL[i]; 
if (TEMP([1) = '(') then 
LEFT PAREN := true; 
if LEFT PAREN then 
begin { LEFT _PAREN } 
if TEMP(d)— 0 ene 
ERSOLi 2) s= * : 
+ TEMP 
else 
ERSOu( i=) + TEMP: 
end; { LEFT PAREN } 
if (ERSQL[i+1] = SENTINEL) and 
LEFT PAREN then 
ERSQL[i] := ERSQL[i] + ')'; 
writeln(ERSQL[i]); 
1. t=oa eee 
end; { ERSOL[1)] <> SENTINEL 
end; { ESQL VIEW } 


procedure SQL VIEW; 


var 
re -ehar-: 
i: integer; 
j: DEPT SET; 
k: JOBS; 


CONTINUE, DONE, SETTABLE1, 
SETTABLE2, SETTABLE3, SETTABLE4: boolean; 


procedure TRANS MAJOR(VAR CONTINUE, DONE, SETTABLE1, 
SETTABLE2 ,SETTABLE3, SETTABLE4: 
boolean; VAR i:integer; 
a DEPT SET; k:JOBS) ; 
begin { TRAN MAJOR } 


if ERSQL[i] = 'WHERE MAJOR = "COMP.SCI."' then 
SQL[i] := 'WHERE IDNAME = "COMP.SCI."! 
else if ERSQL[i] = 'WHERE MAJOR <> "COMP.SCI."' 
then SQL[i] := 'WHERE DIDNAME <> "COMP.SCI."! 
else if ERSQL[i] = ‘AND MAJOR = "COMP.SCI."! 
then SQL[i] := 'AND DIDNAME = "COMP.SCI."! 
else if ERSQL[{i] = 'AND MAJOR <> "COMP.SCI."! 
then SQL[i] := 'AND DIDNAME <> "COMP.SCI."! 
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end; 


else if ERSQL[{i] = 'WHERE MAJOR = "MATH"' then 


SQL[i] := 'WHERE DIDNAME = "MATH"! 

else if ERSQL[i] = 'WHERE MAJOR <> "MATH"! then 
SQL[i] := 'WHERE DIDNAME <> "MATH"! 

else if ERSQL[i] = 'AND MAJOR = "MATH"' then 
SQL[i] := 'AND DIDNAME = "MATH"! 

else if ERSQL[i] = 'AND MAJOR <> "MATH"' then 
SQL[i] := 'AND DIDNAME <> "MATH"! 

else if ERSQL[i] = 'WHERE MAJOR = "MUSIC"' then 
SQL[i] := 'WHERE DIDNAME = "MUSIC"! 

else if ERSQL[i] = 'WHERE MAJOR <> "MUSIC"' then 
SQL[i] := 'WHERE DIDNAME <> "MUSIC"! 

else if ERSQL[i] = 'AND MAJOR = "MUSIC"' then 
SQL[i] := 'AND DIDNAME = "MUSIC"! 

else if ERSQL[i] = 'AND MAJOR <> "MUSIC"' then 
SQL[i] := 'AND DIDNAME <> "MUSIC"! 

else if ERSQL[i] = 'WHERE MAJOR <> "PHYSICS"! 
then S@L[i] := "WHERE DIDNAME <> “PHYSICS"' 
else if ERSQL[i] = 'AND MAJOR = "PHYSICS"! 
then SQL[i] := 'AND DIDNAME = "PHYSICS"! 

else if ERSQL[i] = 'AND MAJOR <> "PHYSICS" 
then SQL[i] := 'AND DIDNAME <> "PHYSICS"! 
else if ERSQL[i] = 'WHERE MAJOR = "PHYSICS"! 
then SQL[i] := 'WHERE DIDNAME = "PHYSICS"! 

else if ERSQL[i] = 'WHERE MAJOR <> "HISTORY"! 
then SQL[{i] := 'WHERE DIDNAME <> "HISTORY"! 
else if ERSQL[i] = 'AND MAJOR = "HISTORY"! 
then SQL[i] := 'AND DIDNAME = "HISTORY"! 

else if ERSQL[i] = 'AND MAJOR <> "HISTORY"! 
then SQL{i] := 'AND DIDNAME <> "HISTORY"! 
else if ERSQL[i] = 'WHERE MAJOR = "HISTORY"! 
then SQL[i] := 'WHERE DIDNAME = "HISTORY"! 

else CONTINUE := TRUE; 


if (not SETTABLE1) and (not SETTABLE2) and 
(not SETTABLE3) and (not SETTABLE4) and 
(1 = 2) then 
begin { SETTABLE } 
SQL[2] := ERSQL[2] + ', IDDEPT'; 
SETTABLE1 := true; 
end { SETTABLE } 
else if (not SETTABLE1) and (i > 2) then 
begin { SETTABLE } 


SQL[2] := SQL[2] + ', IDDEPT'; 
SETTABLE1 := true; 

end; { SETTABLE } 

if not CONTINUE then begin 

MAJOR := FALSE; 

DONE := true; 

end; 


{ TRAN MAJOR } 


Lol 


begin { TRANS DEPT } 
"WHERE DEPT = 


if ERSOL( i ).= 
SOLipt | ' WHERE 
else if ERSQL[i] 
then SQL[i] 
else if ERSQL[i] 
then SQL[i] 
else if ERSQL[i] 
then SQL[i] := 
else if ERSQL[i] 
SQL[i] := 'WHERE 
else if ERSQL[i] 
SQL[i] := 'WHERE 
else if ERSQL[1i] 
SQL(i] "AND 

else if ERSQL[i] 
SQL[i] := 'AND 

else if ERSQL[i]} 
SQL[i] 'WHERE 
else if ERSQL[i] 
SQOL[i] ' WHERE 
else if ERSQL[i] 
SQL([i] := 'AND 

else if ERSQL[i] 
SQL[i] "AND 

else if ERSQL[i] 
then SQL[i] 
else if ERSQL[i] 
then SQL[i] 
else if ERSQL[i] 
then SQL[i] 
else if ERSQL[i] 
then SQL[i] 
Glee if ERSOL[1} 
then SQL[i] 
else if ERSQL[i] 
then SOnii |) -— 
else if ERSQL[i] 
then SQL[(i] 
else if ERSQL[i] 
then SQL[i] 
else CONTINUE 


procedure TRANS _DEPT(VAR CONTINUE, DONE, SETTABLE1, 


SETTABLE2, 
SETTABLE4: 
integer; j: 


SETTABLE3, 
boolean; VAR i: 
DEPT SET; Kswione is 


maa 


wae 


UGOMP. 3 Git 


DIDNAME = "COM> Sei. 
= 'WHERE@ Ob?! <> “GOMe {sci 
"WHERE  DIBNAME <> "COMP 7S¢I,™! 
= 'AND DEEL = “COMP .SCr. 
"AND DIDNAME = “COMP sSCr."* 
= 'AND DEPT <> “GOMP.SCil.:™ 
"AND DIDNAME <> "COMPyscr. 
= 'WHERE DEPT = "MATH"' then 
DIDNAME = "MATH"! 
= 'WHERE DEPT <> "MATH"' then 
DIDNAME <> "MATH"! 
= 'AND DEPT = "MATH"! then 
DIDNAME = "MATH"! 
= 'AND DEPT <> "MATH"! then 
DIDNAME <> "MATH"! 
= 'WHERE DEPT = "MUSIC"' then 
DIDNAME = "MUSIC"! 
= 'WHERE DEPT <> "MUSIC"! then 
DIDNAME <> "MUSIC"! 
= 'AND DEPT = "MUSIC"' then 
DIDNAME = "MUSIC"! 
= 'AND DEPT <> "MUSIC"! then 
DIDBNAME <> "MUStC"™* 
= 'WHERE DEPT <> "PHYSICS"! 
"WHERE DIDNAME <> "PHYSICS"! 
= 'AND DEPT = "PHYSICS"! 
"AND DIDNAME = "PHYSICS"! 
= 'AND DEPT <> UPHYSiI¢SsS™! 
"AND DIDNAME <> "PHYSICS"! 
= 'WHERE DEPT = "PHYSICS"' 
"WHERE DIDNAME = "PHYSICS"! 
= "WHERE SDEPT <>)"HISTORY™* 
"WHERE DIDNAME <> "HISTORY"! 
= 'AND DEPT = VHiSTORY 
"AND DIDNAME = "HISTORY"! 
= 'AND DEPT <> "YHISZORY"' 
"AND DIDNAME <> "HISTORY"! 
= 'WHERE DEPT = "HISTORY"! 
"WHERE DIDNAME = "HISTORY"! 


:= true; 


La2 


ie (hoe oh llarhe.) ands (net SETTABLE2) and 
(not SETTABLE3) and (not SETTABLE4) and (i = 2) 
then begin { SETTABLE } 
SObi2) t= ERSOL([2) + ", IDDEPT"; 
SETTABLE1 := true; 
end { SETTABLE } 
else if (not SETTABLE1) and (i > 2) then 
begin { SETTABLE } 
SOmi2ies— SOChi2) 4. °, LDDEPT’; 
SETTABLE1 := true; 
end; { SETTABLE } 
if not CONTINUE then begin 
DEPT := FALSE; 
DONE := true; 
end; 
end; { TRANS DEPT } 


procedure TRANS JOBTYPE(VAR CONTINUE, DONE,SETTABLEI, 
SETTABLE2 ,SETTABLE3, 
SETTABLE4: boolean; 
VAR i: integer; j: DEPT_SET; 


k: JOBS) ; 

begin { TRANS JOBTYPE } 
if ERSQL[i] = 'WHERE JobType = "FACULTY"! 
then SQL[{i] := 'WHERE EIDNAME = "FACULTY"! 
else if ERSQL[i] = 'WHERE JobType <> "FACULTY"! 
then SQL[{i] := 'WHERE EIDNAME <> "FACULTY"! 
else if ERSQL[i] = 'AND JobType = "FACULTY"! 
then SQL[i] := 'AND EIDNAME = "FACULTY"! 
else if ERSQL[i] = 'AND JobType <> "FACULTY"! 
then SQL{i] := 'AND EIDNAME <> "FACULTY"! 
else if ERSQL[{i] = 'WHERE JobType = "SECRETARY"! 
then SQL{i] := 'WHERE EIDNAME = "SECRETARY"! 
else if ERSQL[i] = 'WHERE JobType <> "SECRETARY"! 
then SQL[i] := 'WHERE EIDNAME <> "SECRETARY"! 
else if ERSQL[{i] = 'AND JobType = "SECRETARY"! 
then SQL[i] := 'AND EIDNAME = "SECRETARY"! 
else if ERSQL[i] = 'AND JobType <> "SECRETARY"! 
then SQL[i] := 'AND EIDNAME <> "SECRETARY"' 
else CONTINUE := true; 


if (not SETTABLE2) and (not SETTABLE1) and 
(not SETTABLE3) and (not SETTABLE4) and (i = 2) 
then begin { SETTABLE } 
SQOL( 2] := ERSOE[2] + ", IDEMP'; 
SETTABLE2 := true; 
end { SETTABLE } 


Sy: 


else if (not SETTABLE2) and (i > 2) then 
begin { SETTABLE } 
SOL(2) 3= SUnb2 |). =e Le nites, 
SETTABLE2 := true; 
end; { SETTABLE } 


if not CONTINUE then begin 
JOBTYPE := FALSE; 
DONE := true; 

end; 


end; { TRANS JOBTYPE } 


procedure TRANS WORKSFOR(VAR CONTINUE,DONE, SETTABLE1, 


SETTABLE2, SHETABLES, 
SETTABLE4: boolean; 
VAR i: integer; 3: DEPT SET; 


k: JOBS) ; 
begin { TRANS WORKSFOR } 
if ERSQL[i] = 'WHERE WorksFor = "COMP.SCI."' then 
SQL[i] := 'WHERE DIDNAME = "COMP.SCI."'! 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


else 


if ERSQL[i] 
then SQL[i] 


"WHERE WerksPFor <> "COMP3sci.@ 
= 'WHERE DIDNAME <> "COMP.SCI."' 


if ERSQL[i] = 'AND WorksFor = "COMP.SCI."! 
then SQL[i] := 'AND DIDNAME = "COMP.SCI."! 
if ERSQL[{i] = 'AND WorksFor <> "COMP.SCI."! 
then SQL[i] := 'AND DIDNAME <> "COMP.SCI."' 
if ERSQL[i] = 'WHERE WorksFor = "MATH"' then 
SQL[i] := 'WHERE DIDNAME = "MATH"! 
if ERSQL[i] = 'WHERE WorksFor <> "MATH"' then 
SQL[i] := 'WHERE DIDNAME <> "MATH"! 
if ERSQL[i] = 'AND WorksFor = "MATH"! then 
SQL[i] := 'AND DIDNAME = "MATH"! 
if ERSQL[i] = 'AND WorksFor <> "MATH"! then 
SQL[i] := 'AND DIDNAME <> "MATH"! 
if ERSQL[i] = 'WHERE WorksFor = "MUSIC"' then 
SQL[i] := 'WHERE DIDNAME = "MUSIC"! 
if ERSQL[i] = 'WHERE WorksFor <> "MUSIC"' then 
SQL[i] := 'WHERE DIDNAME <> "MUSIC"! 
if ERSQL[i] = 'AND WorksFor = "MUSIC"' then 
SQL[i] := 'AND DIDNAME = "MUSIC"! 
if ERSQL[1i] = 'AND WorksFor <> "MUSIC"! then 
SQL[i] := 'AND DIDNAME <> "MUSIC"! 
if ERSQL[i] = 'WHERE WorksFor <> "PHYSICS"! 
then SQL[i] := 'WHERE DIDNAME <> "PHYSICS"! 
if ERSQL[i] = 'AND WorksFor = "PHYSICS"! 
then SQL[i] := 'AND DIDNAME = "PHYSICS"! 
if ERSQL[i] = ‘AND WorksFor <> "PHYSICS"' 
then SQL[i] := 'AND DIDNAME <> "PHYSICS"! 
if ERSQL[i] = 'WHERE WorksFor = "PHYSICS"! 
then SQL[i] := 'WHERE DIDNAME = "PHYSICS"! 
if ERSQL[1) = ‘WHERE  WorksFor <> 3 History. 
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Ghen sOLitiie:= 'WHERE DIDNAME <> “HISTORY™' 


else if ERSQL[i] = 'AND WorksFor = "HISTORY"! 
then SQL[i] := 'AND DIDNAME = "HISTORY"! 
else if ERSQL[i] = 'AND WorksFor <> "HISTORY'"' 
then SQL[{i] := ‘AND SEV AME <>" "HISTORY! 
else if ERSQL[i] = 'WHERE WorksFor = "HISTORY"! 
then SQL[i] := 'WHERE DIDNAME = "HISTORY"! 
else CONTINUE := true; 


if (not SETTABLE1) and (not SETTABLE2) and 
(not SETTABLE3) and (not SETTABLE4) and 
(1 = 2) then 
begin { SETTABLE } 
SOni2i:—= ERSOLp2| + %, IDDEPT"> 
SETTABLE1 := true; 
end { SETTABLE } 
else if (not SETTABLE1) and (i > 2) then 
begin { SETTABLE } 
SOli2 |) = Soll 2) +“, LDDEER’: 
SETTABLE1 := true; 
end; { SETTABLE } 
if not CONTINUE then begin 
BEE. s— FALSE; 
DONE := true; 
end; 


end; { TRANS WORKSFOR } 


procedure TRANS MEMBERS (VAR CONTINUE, DONE, SETTABLE1, 
SHITABLE2Z, SE TTABLES, 
SETTABLE4: boolean; 
VAR i: 
iicegcm ama DEPT SET; k:JOBS) ; 
begin { TRANS MEMBERS } 


if ERSQL[i] = 'WHERE MEMBERS = LUM! 

then SQL[i] := 'WHERE FIDNAME = "LUM"! 

else if ERSQL[i] = 'WHERE MEMBERS <> "LUM"! 
then SQL{i] := 'WHERE FIDNAME <> "LUM"! 

else if ERSQL[i] = 'AND MEMBERS = "LUM"! 

then SQL[i]) := 'AND FIDNAME = "LUM"! 

else if ERSQL[i] = ‘AND MEMBERS <> "LUM"! 
then SQL{i] := 'AND FIDNAME <> "LUM"! 

else if ERSQL{[i] = 'WHERE MEMBERS = "JOHNSON"! 
then SQL[i] := 'WHERE FIDNAME = "JOHNSON"! 

else if ERSQL[i] = 'WHERE MEMBERS <> "JOHNSON"! 
then SQL[i] := 'WHERE FIDNAME <> "JOHNSON"! 
else if ERSQL{i] = 'AND MEMBERS = "JOHNSON"! 
then SQL[i] := 'AND FIDNAME = "JOHNSON"! 

else if ERSOL[i] = ‘AND MEMBERS <> "JOHNSON"! 
then SQL[i]) := ‘AND FIDNAME <> "JOHNSON"! 
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else CONTINUE := true; 
if (not SETTABLE2) and (not SETTABLE1) and 
(not SETTABLE3) and (not SETTABLE4) and (i = 2) then 
begin { SETTABLE } 
SQOL(2]) := ERSOL|(2]) + Sel becom’ 
SETTABLE3 := true; 
end { SETTABLE } 


else if (not SETTABLE3) and (i > 2) then 
begin { SETTABLE } 
SQL[2] := SOL[2]) + ")) ipeompe’- 
SETTABLE3 := true; 
end; { SETTABLE } 


if not CONTINUE then begin 
JOBTYPE := FALSE; 
DONE := true; 
end; 
end; { TRANS MEMBERS } 


begin { SQL VIEW } 
Le a 
writeln; 
writeln; 
write ('HIT ENTER TO VIEW SEQUEL QUERY Pad. 
readin, (re 


Cleser; 

SETTABLE1 := false; SETTABLE2 := false; 
SETTABLE3 := false; 

SETTABLE4 := false; 

CONTINUE := false; 

DONE := false; 

SOL{[1] := ERSGL[1]; 


while ERSQL[i] <> SENTINEL do begin 
if MAJOR then 
TRANS MAJOR( CONTINUE, DONE, SETTABLE1, 
SETTABLE2, SETTABLE3, 
SETTABLE4, i, j, k); 
if DEPT and not DONE then 
TRANS DEPT( CONTINUE, DONE, SETTABLE1, 
SETTABLE2, 
SETTABLE3, SETTABLE4, i, j, Kk); 
if JOBTYPE and not DONE then 
TRANS JOBTYPE ( CONTINUE, DONE, SETTABLE1, 
SETTABLE2, SETTABLE3, 
SETITABLEA ss oe 
if WORKSFOR and not DONE then 
TRANS WORKSFOR ( CONTINUE, DONE, SETTABLE1, 
SETTABLE2, 
SETTABLE3, SETTABLE4, i, j, k); 
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if MEMBERS and not DONE then 
TRANS MEMBERS ( CONTINUE, DONE, SETTABLEL, 


SETTABLE2, 
SEMEAELE, SEUTABLES, I, 3, K)+ 
fos — 4 1S 
SQL[i] := ERSQL[i]; 
DONE := false; 
CONTINUE := false; 


end; { ERSQL[i] <> SENTINEL } 


mor v= 1 to 5 do writeln; 

ioe s= 1; 

while SQL{i] <> SENTINEL do 

begin { while SQL[i] <> SENTINEL } 
writeln (SQL[i]); 
NS ea en Im oe 

end; { while SQL[i] <> SENTINEL } 

end; { SQL VIEW } 


procedure START_UP; 

begin { START UP} 
INITIALIZE GLOBALS; 
LOAD_OBJECTS; 
LOAD WINDOWS _WITH_OBJECTS; 
DISPLAY QUERY OPTIONS; 
HOW MANY PARTIAL QUERIES 


(NO_PARTIAL QUERIES IN QUERY) ; 
end; { START_UP } 


procedure GET_AND_ REVIEW OUTPUT; 
var 
i: integer; 
begin { GET AND REVIEW OUTPUT } 
it — 1; 
ESQL VIEW; 
SQL VIEW; 
writeln(FSQL); writeln(FSQL) ; 
writeln(FSQL, 'EXTENDED SEQUEL QUERY IS AS FOLLOWS:'); 


writeln(FSQL); 
while ERSQL[i] <> SENTINEL do 
begin 
Writeln(PSOlL, ERSOL (1); 
i eels oa 
end; 
is — 1; 
writeln(FSQL); writeln(FSQL) ; 
writeln(FSQL, 
'TRANSLATED SEQUEL QUERY IS AS FOLLOWS:'); 
wiereelin( PSOL) 5 


Ts 7. 


while SQL[i}] <> SENTINED de 
begin 
writein(FSOL, SOLiIIn: 
i, f= ele 
end; 
writeln(FSQL); writeln(FSQL) ; 
end; { GET AND REVIEW OUTPUT } 


procedure RESET GLOBAL COUNTER; 


begin 
x s= Ay 

end; 

begin { ObjectTranslator } 
FINISHED := false; 


assign (FPSOQL, 'SEQUEL.SOem@, 
rewrite (FSQL); 


REPEAT { Until all the queries are completed } 
START _UP; 


SELECT (e) ; 
FROM(e,e+1) ; 
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(KkKK KARR KKK KKK TRANSLATION ALGORITHM *#* kk eKKKKK } 


if (MORE THAN ONE OBJECT USED IN QUERY) then 
JOIN OBJECTS; 


Bor il := EQ NOPPART EAD ;OURBRTaS TN OUERY do begin 


if (INSTRUCTIONS ON OBJECT NAME(i)) then 
OBJ OPERATIONS (i); 


while (EXECUTE AND DECODE(i)) do 
begin { while (EXECUTE AND DECODE) } 
if (ASTERISK FOR ATTRIBUTE NAME(i)) and 
EXISTENTIAL QUANTIFIER(i) then 
SPECIAL OPS (i) 
else if (DOT P ON ATTRIBUTE(i)) then 
RETRIEVE SELECT (i) 
else if (NO _INSTRUCTIONS(i)) then NO _OP(i) 
else if (INSTRUCTIONS ON ATTRIBUTE(i)) then 
RELATIONAL OPERATORS; 
end; { while (EXECUTE_AND DECODE) } 


if (not EXECUTE_AND_DECODE(i)) then 
RESET GLOBAL COUNTER; 


end; { for i := 1 to NO _PARITAL QUERIES IN QUERY } 


{ KHRKKKEKKKKKKKKERKEKEKKEKKKKKKKKKKKKRKKKRKKKKRKRKKKKRKRKRKKKKKRK RE 


end. 


GET AND REVIEW OUTPUT; 
writeln; writeln; 
write('ENTER "F" OR "£" TO STOP MAKING QUERIES ':60); 
readln(F); 
me (fF = "F') or (F = "£') then FINISHED := true; 
UNTIL FINISHED; 
close (FSQL); 
{ ObjectTranslator } 
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APPENDIX B 


TRANSLATOR OUTPUT 


KRREKEKKKKKKREREKRKRRKRRRRRRERRRRERRRRRRRRRRRRKEKRRRRKKRREE 


* STUDENT QUERY * 
KKK KKK KKK KK KKK RK KEK KEK KEK KERR KER KKK KKK KR KKK KK RKKRKEK 
* STUDENT * * 
* * * * 
* SNAME * ae * 
* ADDRESS * * 
*  SSNO * * 
* GPA * 2 — oD * 
* MAJOR * * 


RREEKEEKRRRRKRRERERRRRRRKRRRRKRRRRRRRRRERRRRERRRRRRERRRREER 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT SNAME 

FROM STUDENT 

WHERE GPA >= 3.5 

TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 
SELECT SNAME 


FROM STUDENT 
WHERE GPA >= 3.5 


KRHKKEKKKKKEKKEKKEKEKKEKEKRKKKRKEERKEKRKKRKRKRRRKREKEKEEKRERKKRRKEKRKKREKRE 


* FACULTY QUERY * 
KKK KKK KK KKK KKK KKK KKK KKK KR KK KK KKK RRR KKK RRR KKK 
* FACULTY * * 
* FNAME * ~P * 
* AGE * >= 30 * 
* WorksFor * * 


KRREKKKKKKEKKEKRKEKREKRKRRRRERRREKKKKERKERERRRKRREEKKRRKRRRERE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT FNAME 


FROM FACULTY 
WHERE AGE >= 30 
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TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT 
FROM 
WHERE 


FNAME 
FACULTY 
AGE >= 30 


KKEKKERKKKKKKKKEEKRERERKKKKEKKKEREKKKEKRKEKEKEKKKKKRKKEKKEEKEK 


* EMPLOYEE QUERY * 
KEKKKKEKEKKEKKKKKEKKEKKEKKEKKEKEKRKKRKKRKKKKKKKKRKKRRKKKKKKKKKEE 
* EMPLOYEE * * 
* ENAME * = 18 * 
*x* PAY * >= 30,000 * 
- DEPT * * 
*  JobType * * 
KREKEKEKREKRKKERERKKEKEKRREKEKKRKKEKEKRKKRKRKKKKRKRKRKRKKKRKRRKKKREKEE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT ENAME 


FROM 


EMPLOYEE 


WHERE PAY >= 30,000 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT ENAME 


FROM 


EMPLOYEE 


WHERE PAY >= 30,000 


KHKAEKKKKKEKKKKEKEKKEKEKEKKKEKKEREKEKEKEEKKEKERKKRKKKKKKKKKRKEKKREKEKE 


* COMMITTEE QUERY * 
KRKRKKKRKRKRKKKRKRKKKKRKRKKKKRKRKRKKRKKRKKRKRKRKKKRKKKRKRKRK KKK KKK 
* COMMITTEE * * 
* CNAME * .P * 
* MEMBERS * * 
* PURPOSE * = "RECRUITING" * 


KREEKEEKKEKKKEKKKKEEKKKKRKEKKKKRKRKEKKKRKRKRKKKKKKKRKRKRKKKRKRKKRKRKRKEEE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT CNAME 


FROM 
WHERE 


COMMITTEE 
PURPOSE — "RECRUITING" 
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TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT CNAME 


FROM 


COMMITTEE 


WHERE PURPOSE = "RECRUITING" 


KHER KKRKKEKKKKEKERRREKKKKRRRRKRKRKKRKRRKRKRKRKRRRKRKRKRKRKRKKKK 


* STUDENT QUERY * 
KKK KKK KKK KEK KKK KEK 
* STUDENT * x 
* * * COUNT * 
*  SNAME * * 
* ADDRESS * * 
* SSNO * * 
* GPA * * 
* MAJOR * * 
KAKA 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT (*) 


FROM 


STUDENT 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT (*) 


FROM 


STUDENT 


KHRKEKRKEKEKEKERKRREREKKKKRREKREKKRKKKRKERKEKKRKRKKKKKKKKKRKKKKEKEE 


* STUDENT QUERY * 
KKK K 
* STUDENT * * 
* * * -P * 
*  SNAME * * 
* ADDRESS * * 
* SSNO * * 
* GPA * * 
* MAJOR * * 
KHKKKKKKKKKKKKKKKKKKKKKHEKKKKKKKKKKKRHKKKKKKKRKKKKKKEKE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT STUDENT. * 


FROM 


STUDENT 


te2 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT STUDENT. * 


FROM 


STUDENT 


KRREKEKKEKKKEKRKEKKEKRREKKEKRRREREKRRERERRKERERREREKRKKEKKREKEREE 


* EMPLOYEE QUERY * 
KEKE 
* EMPLOYEE * * 
*  ENAME * -F -COunT * 
* PAY * 220,000 * 
* DEPT * * 
* JobType * * 
KEEKKKKEKKEKKEKKKERREKKEREKEKRRERKRRREREKKERRKEKRKRERKRKRKRKRREKEE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT (ENAME) 


FROM 


EMPLOYEE 


WHERE PAY > 20,000 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT (ENAME) 


FROM 


EMPLOYEE 


WHERE PAY > 20,000 


RREKEKEREKEKEKEKEKRRREKRKEKREKRRRKRKRRRRRKRKRRRKRRRKRKRRKKRKKKRKKRRKEEK 


* FACULTY QUERY * 
KKK KKK KKK KK KK KK KKK RRR KKK KR KKK KKK RRR KKK KKRAR RRR 
* FACULTY * * 
* FNAME * * 
* AGE * -P * 
* WorksFor * * 


KKEEKKKKKKEKEKKEKEKREKRKEKEKRREKEKRKEREKRRKERERKEKRKRREKRRKRREKRRKRREKREE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT AGE 


FROM 


FACULTY 


G3 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT AGE 


FROM 


PACUIETY 


RRREKRKRRRRRRRRRRRKRRRRRRRRKRRRRRRRRKKRRRRKRKRKRRRRRRRRKRRERE 


* STUDENT QUERY * 
Ge i ee Ee ee ee ee ee ee i ee Ee, i, re 
* STUDENT x * 
* * * * 
*  SNAME x .P * 
* ADDRESS * * 
* SSNO * * 
* GPA * >= 3.0 * 
* MAJOR * * 
Pe i i re i i re, ee ee ee, 


KRREEEKEKEERERRERRRRREEKEEERRKEKERKEEKEKEERRREREKRRERKEKEKKEERER 


* EMPLOYEE QUERY * 
KEKERKKEKKKEKEKRERKEKREEERKEKEKKKKKKKRRKRERRRRRKKKREKKEKRKKAKKE 
* EMPLOYEE * * 
* ENAME * = SNAME * 
* PAY x >=) 20,000 * 
* DEPT * * 
* JobType * * 
KKK RRRRRREREREKERRERREREKRRRKEKRRRRRRRRRRRRRRRER 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT SNAME 


FROM 
WHERE 
AND 
AND 


STUDENT, EMPLOYEE 
GPA >= 3.0 

ENAME = SNAME 

PAY >= 20,000 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT SNAME 


FROM 
WHERE 
AND 
AND 


SIUDENT, EMPLOYEE 
GPA >= 3.0 

ENAME = SNAME 

PAY >= 20,000 


164 


KKK RR KER KR Xe cece Secs oe ee ee ee Ee ee ek eo eK ee ke tok ee ek ee 


* EMPLOYEE CURRY * 
CA nS Cad Tad CaS AS AR AS AS CA A TAT PAS TAT DD PD AD THOT Ad APCD CAT Cas AREAS a cad ead CAN eA at rad ad TA WS AS AR Cs CAT RAPED CAM CATICAT Cad KARE AD 
* EMPLOYEE * * 
*  ENAME * -P * 
* PAY * >= 30,000 * 
* DEPT * * 
* JobType * * 
KREKEKEKKKKREKREEKRKEK REE KKK KKK 


RREKEKRKERKEKEKERKEKKEKKRERKKEKEKKERKRKRKKRRKRK RRR E 


* FACULTY QUERY * 
KRERKEKKERKEKERKKRKEKREREKRKEKRKREKEKRRKRKEKRRKKEKRKKEKKEKRKRKRKKKRKEKERK 
* FACULTY * * 
* FNAME * = ENAME * 
* AGE * >= 30 * 
* WorksFor * * 


RREEKKRRERRERRRRREEKKRRERKREKRKEKRREKKRRRERRERRERKKRRRRRRRKRRRER 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT ENAME 


FROM 
WHERE 
AND 
AND 


EMPLOYEE, FACULTY 
PAY >= 30,000 
FNAME = ENAME 

AGE >= 30 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT ENAME 


FROM 
WHERE 
AND 
AND 


EMPLOYEE, FACULTY 
PAY >= 30,000 
FNAME = ENAME 

AGE >= 30 
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KREKKRKEKEKKRKEKRKEKKKREREEKKEKRKKRKEEKRKKKRRKEKKKRRKEKRKRKKKERRKKKEEK 


* FACULTY QUERY * 
KKK 
* FACULTY * * 
* * * COUNT * 
* FNAME * -P * 
* AGE * >= AVG(AGE) * 
* WorksFor * * 
KERR RRERKEKKRRRRKRRRRRRRRKRKKRKRRKKRAREE 


KRREKKKEKRKEKEKREREKRKKKERREKKREKRKKREKRKKRKRRREKRKRREKRREKRKRKEKRKKKER 


* COMMITTEE QUERY * 
KERR 
* COMMITTEE * * 
* CNAME * = FNAME * 
* MEMBERS * * 
* PURPOSE * = "RECRUITING" * 


KRREEKKKEKREREKRKREKEKRKRRERERKEKREKREKRKRREKREKRKRKREKRERKEKRKEKRKREEEE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT(*), FNAME 


FROM 
WHERE 
AND 
AND 


FACULTY, COMMITTEE 
AGE >= AVG(AGE) 

CNAME = FNAME 

PURPOSE = "RECRUITING" 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT COUNT(*), FNAME 


FROM 
WHERE 
AND 
AND 


FACULTY, COMMITTEE 
AGE >= AVG(AGE) 

CNAME = FNAME 

PURPOSE = "RECRUITING" 


166 


KKEKKEKKREKRKKEKREKEKEKKEKKRKEKREKKEKKRKEKEKEKKEKKKRKEKKREKKKEKE 


* STUDENT QUERY * 
KK KKK KKK KKK KKK KKKKRKKEKRKEKKRKKKKKKRKKKKEKKKRKKKKKEEKE 
* STUDENT * * 
* * * * 
*  SNAME * =P * 
* ADDRESS * * 
*  SSNO * * 
2 CPA * re Ae * 
* MAJOR * * 
Ka KKK KK KKK KKK KKKKKKKKKEKKKEKKKKEKEKKKKEKKKKEKEKKEKKKEKKKEEKE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT SNAME, AVG(GPA) 

FROM STUDENT 

TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT SNAME, AVG(GPA) 
FROM STUDENT 


KREKKEKEKKEKKKEKEKKEKKEKRKRKEKEKREKEKKKEKEKKKKRKEKKKKKEKEKER 


* EMPLOYEE QUERY * 
KEKKKKREKREKKKKKKKKKEKRKEKRKKE KKK KKKKKKKKKEKKEKKEKKKKKKKEKSE 
* EMPLOYEE * * 
*  ENAME * * 
2 fey * -P MAX * 
* DEPT * * 
*  JobType * = "SECRETARY" * 
KEKKKEKKKKKEKKKEKEKEKRKREKREKKKKEKKEEKEEKKKRKEKRKEKKKKKEEKKER 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT MAX (PAY) 

FROM EMPLOYEE 

WHERE JobType = "SECRETARY" 
TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 
SELECT MAX (PAY) 


FROM EMPLOYEE, IDEMP 
WHERE EIDNAME = "SECRETARY" 
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KREKKKKEKKKEKKKEKEKKKEEEREKEKEKKKEKEKEKKKRKRKREKKRREKEKKKKKKKKKEE 


* FACULTY QUERY * 
KKK E 
* FACULTY * * 
* FNAME * * 
* AGE * -P MIN * 
* WorksFor * * 


KRKEEKRKKKRKEKKKEKKRKEKKRRERRKKRRKRRKRRKRKRKRRRKKRKKRKKRKKRKRKRKEKEE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT MIN(AGE) 

FROM FACULTY 

TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 


SELECT MIN(AGE) 
FROM FACULTY 


KKREKRKEKREKKKEKKRKRRERKRKRREKRERKRREKRRKRKERKEREKKRKRKRKKRKREKRKEEE 


* COMMITTEE QUERY * 
KEKE ESE 
* COMMITTEE * * 
* CNAME * .P COUNT * 
* MEMBERS * * 
* PURPOSE * = "RECRUITING" * 


KRKEREKKERKEKEKKEKKRKEREKEKKKKKRRERKEKKKKKKKKKKRKRKRKKRKKKRKEKKEKE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT COUNT (CNAME) 


FROM COMMITTEE 
WHERE PURPOSE = “RECRUITING" 


TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 
SELECT COUNT (CNAME) 


FROM COMMITTEE 
WHERE PURPOSE = “RECRUITING” 
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KREKKEKKKEKKEKRREKRKEKKKEKEKKKKEKKKKKEKKKRKREKRRREKEKEKRREKREKEEK 


* 


* STUDENT QUERY 

KH KKKKKKKKKEKKKEKKKRKKKKKKKEKKRKKKRKEKRKRKRERKKRRRKRKRRRKEE 
* STUDENT * 

* * * 

*  SNAME * 58 

* ADDRESS * 

* SSNO * 

Ses * .P MAX 

* MAJOR * 


KRHKEEKKKEKKKRERKKEKKKERKERRRRERRKRRREKRKRRRRRKRKRRRRKRRKRRRRREKRE 


EXTENDED SEQUEL QUERY IS AS FOLLOWS: 
SELECT SNAME, MAX(GPA) 

FROM STUDENT 

TRANSLATED SEQUEL QUERY IS AS FOLLOWS: 
SELECT SNAME, MAX(GPA) 


FROM STUDENT 


** NOTE : With the simulator, * is displayed in window 
for STUDENT object and only when needed for 
the query with the other objects. 


Ife) 


k 
* 
* 
* 
* 
* 
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